From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 01:02:21 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 13:32:21 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> My serial port driver(apparently) does not support receive timeout.I registered an event listener for DATA_AVAILABLE. However, the control never seems to come out of the 'while' loop.Shouldn't the InputStream.read return a '-1' immediately if no data is available (this seems to be the default operation)? This was tried on a x86 Linux desktop using rxtx-2.1-7 I've added the snippet for clarity: /******************************************************************************************************************************************************************************/ mySerialPort.enableReceiveThreshold(2000);//Trying to set a time limit for read calls System.out.println(mySerialPort.isReceiveTimeoutEnabled()); // I get FALSE, so its not supported on hardware. mySerialPort.addEventListener(this); mySerialPort.notifyOnDataAvailable(true);//register a event with //my SerialEvent listener implementation: public void serialEvent(SerialPortEvent arg0) { int newData=0; switch(arg0.getEventType()){ case SerialPortEvent.DATA_AVAILABLE: while (newData != -1) { try { newData = is.read();//This should eventually return a -1 if no data is available within a timeout.PROBLEM!! System.out.println("Got a byte from port:"+newData); if (newData == -1) { break; } } catch (IOException ex) { System.err.println(ex); return; } } break; } return; } /******************************************************************************************************************************************************************************/ Thanks and regards, Ravi From michael.erskine at ketech.com Wed Feb 3 02:26:50 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 09:26:50 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From michael.erskine at ketech.com Wed Feb 3 05:03:30 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 12:03:30 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > Michael Erskine > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > > Your event handler should handle the event and return immediately so that its > controlling thread can handle other events. I recommend a single read in the > following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) > reads all available bytes up to the size of the buffer returning the number of > bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } After posting this I considered the glaring possibility of the rawbuf read buffer being too small to receive all the available bytes and perhaps skipping data: after all, I'm guessing that is why we see so many posts asking for help with blocking implementations of read event handlers looping on "while(bytes are available)". I've spent this morning writing an extensive multi-threaded unit test suite that includes tests with a tiny buffer compared to the amount of data available and found that no data was being skipped. I now want to know why! The SerialPortEvent.DATA_AVAILABLE event must be being fired again if there is more data available on the input stream. If that is the case then it should be heavily documented with good examples in the wiki to avoid the types of developer anguish we see so regularly. BTW: I'm not at liberty to post the JUnit tests as they use my company's unit test suite framework. Regards, Michael Erskine. From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 06:18:04 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 18:48:04 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Hello Michael, I tried out your suggestion but the problem is that the read(rawbuf) blocks until the entire length of the rawbuf array has been read (blocking). I cannot decide on a reasonable size of the array because it varies from 2 bytes to as much as 50 byes (i'm communicating with a modem,each response is of a different length), which is why i wanted to use non blocking calls. But on a side note, read(byte[]) in turn calls the read() in a loop.In the native C function, the read is supposed to return a -1 upon timeout.But my driver does not support timeout.The default timeout value is zero and the linux select call upon zero time out causes an infinite wait.What am i missing...... Thanks and regards, Ravi Date: Wed, 3 Feb 2010 09:26:50 +0000 From: Michael Erskine To: "rxtx at qbang.org" Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: Content-Type: text/plain; charset="us-ascii" > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From m.kirkland at comcast.net Wed Feb 3 06:46:03 2010 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 3 Feb 2010 05:46:03 -0800 Subject: [Rxtx] One port blocking another port In-Reply-To: References: Message-ID: <68768633814F4D7D86761D34F0764FE0@bengal.net> It turns out this is caused by having the RTS/CTS flow control turned on and me not providing a true on the RTS pin. Somehow it seems the port timing out on a read allows the write to proceed. This is not an issue for my application but I wonder if the write should not proceed until the RTS pin is true even if a read times out. mk -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Monday, January 25, 2010 7:48 PM To: Mike Kirkland Cc: rxtx at qbang.org Subject: Re: [Rxtx] One port blocking another port On Mon, 25 Jan 2010, Mike Kirkland wrote: > > Hi All, > > ? > > I have a program that reads from one com port and writes to another com > port. It also does the same thing in reverse (reads from the second com port > and writes to the first one. It basically ties two com ports together. > > ? > > One port is very chatty and has a consent stream of data. The other port has > very little data. > > ? > > Both ports use a 5000 ms (5 second) time out. > > ? > > The issue I am having is that is appears that the first port?s write to the > second port is blocked while the second port is waiting for input. The first > port?s write proceeds only after the second port has timed out. > > ? > > I suppose I could have something twisted around in my code but I was > wondering if this is a know issue? > Hi Kirk, I've not seen a report like this. Perhaps some simple reproduction code will reveal a problem on your end or help us identify a problem in rxtx. I think there are several users doing multiport communication. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Wed Feb 3 07:03:58 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:03:58 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Message-ID: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> 2010/2/3 Ravishankar N > Hello Michael, > [..] > But on a side note, read(byte[]) in turn calls the read() in a loop.In the > native C function, the read is supposed to return a -1 upon timeout.But my > driver > does not support timeout.The default timeout value is zero and the linux > select call upon zero time out causes an infinite wait.What am i > missing...... > > When I have tested RXTX between platforms, I have observed "hangup" inside JNI driver when no data in Linux, is normal thing. Solution was setting the timeout for RXTX when no data from JNI driver. Something like that: commPort.enableReceiveTimeout(10); And it works perfect.... The only difference is that I am NOT using events - I am using continous read in separate thread and if data is available, is parsed and transferred to application using exception. Regards Mariusz > Thanks and regards, > Ravi > > Date: Wed, 3 Feb 2010 09:26:50 +0000 > From: Michael Erskine > To: "rxtx at qbang.org" > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > Message-ID: > > > Content-Type: text/plain; charset="us-ascii" > > > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of > > Ravishankar N > > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > > > My serial port driver(apparently) does not support receive timeout.I > > registered an event listener for DATA_AVAILABLE. However, the control > never > > seems to come out of the 'while' loop.Shouldn't the > > InputStream.read return a '-1' immediately if no data is available (this > seems > > to be the default operation)? > > Your event handler should handle the event and return immediately so that > its controlling thread can handle other events. I recommend a single read in > the following manner: rawbuf is a byte[] of "reasonable" size and the > read(byte[]) reads all available bytes up to the size of the buffer > returning the number of bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } > > This style of reading has worked for me with RXTX on Linux and Windows XP > for a good few years now in railway industry communications systems. Any > timeouts (largely unnecessary in my applications) can be handled elsewhere, > usually at a higher layer. > > Regards, > Michael Erskine. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Feb 3 07:22:55 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 3 Feb 2010 09:22:55 -0500 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: I'm guessing that this is driver specific. I recently had to support a select()/poll() infrastructure for a linux serial DD, its certainly non trivial to support async IO, so I suspect the problem in this case has to do with missing poll infrastructure in the device driver. This also has to coupled with special open flags for the device (which is within the rxtx code) The key routines within a 2.6 kernel linux device driver are shown below (if you have access to it for your particular device) are indicated below (here is a snippet from my device driver c code that supports polling/select). User space code to test this shown below also, note that the device needs to be opened with the O_NONBLOCK option to support the select/poll api // device driver code ..... /* * File operations supported by this driver. */ static struct file_operations iop_fops = { .owner = THIS_MODULE, .check_flags= iop_check_flags, .ioctl = iop_ioctl, .open = iop_open, .poll = iop_poll, // SUPPORT FOR SELECT/POLL infrastructure .read = iop_read, .release = iop_release, .write = iop_write, }; /** * Select/poll/epoll infrastructure. * * @param file * @param wait * * @return */ static unsigned int iop_poll(struct file *filp, poll_table *wait) { struct iop_device *devp = (struct iop_device *)filp->private_data; // the poll_table wait arg is an opaque pointer poll_wait(filp, &devp->readq, wait); // return from poll indicating whether we have read/write data unsigned int mask = 0; if (kfifo_len(devp->rx_fifo)) { mask |= (POLLIN | POLLRDNORM); } // @JC We don't do select on write yet // if (kfifo_len(devp->tx_fifo)) { // mask |= (POLLOUT | POLLWRNORM); // } // Only print out while debugging // if (mask != 0) { // printk (KERN_INFO "%s: [%04x]\n", __FUNCTION__, mask); // } return mask; } /** * device driver blocking and non blocking read function. This * function reads the requested number of bytes from the read * kfifo blocking as required. * * @param filp * @param buf * @param count * @param f_pos * * @return */ static ssize_t iop_read(struct file *filp, char __user *buf, size_t count, loff_t * ppos) { // access appropriate device struct struct iop_device *devp = (struct iop_device *) filp->private_data; ssize_t retval; // support non blocking mode (default) by checking if the kfifo is empty first if ((kfifo_len(devp->rx_fifo)==0) && (filp->f_flags & O_NONBLOCK)) { return -EAGAIN; } // wait for rx_fifo to receive data via receive interrupts retval = wait_event_interruptible(devp->readq, kfifo_len(devp->rx_fifo) != 0); // check for some error condition if (retval) { printk (KERN_ERR "%s: wait_event_interruptible returned[%d]\n", __FUNCTION__, retval); return retval; } // copy max requested bytes from rx_fifo to device buffer // this may still leave bytes in the kfifo for a subsequent read // if we are reading in a loop retval = kfifo_get(devp->rx_fifo, devp->rxbuf, count); // printk (KERN_INFO "%s: [%d] byte(s)\n", __FUNCTION__, retval); if (copy_to_user(buf, devp->rxbuf, retval)) { printk (KERN_ERR "%s: problem copying rx_fifo data to user buffer\n", __FUNCTION__); return -EFAULT; } return retval; } // a selection of my user space code reading via select()/poll()..... // user space open code iop_fd = ::open( deviceName.data(), O_RDWR | O_NONBLOCK); while ((bytes_to_expect - bytes_read) > 0) { // must reinitialize these between select calls fd_set readfds; FD_ZERO( &readfds ); FD_SET( iop_fd, &readfds ); // 1s sec read polling timeout struct timeval timeout; timeout.tv_sec = 1; timeout.tv_usec = 0; int rc = select( FD_SETSIZE, &readfds, NULL, NULL, &timeout ); // read from file when descriptor // indicates data available without blocking if ((rc > 0) && FD_ISSET(iop_fd, &readfds)) { // read into the appropriate offset within the rx_buf int temp = read(iop_fd, rx_buf + bytes_read, bytes_to_expect - bytes_read); if (!temp) { printf("EOF detected with %d bytes expected\n", bytes_to_expect - bytes_read); } else { bytes_read += temp; } } else if (rc < 0){ printf("%s: select on [%s], bytes_read[%d], errno=%d\n", __FUNCTION__, thread_args->device, bytes_read, errno); } else { printf("%s: select on [%s], bytes_read[%d], timeout\n", __FUNCTION__, thread_args->device, bytes_read); } } On Wed, Feb 3, 2010 at 9:03 AM, Mariusz Dec wrote: > > > 2010/2/3 Ravishankar N > >> Hello Michael, >> [..] >> >> But on a side note, read(byte[]) in turn calls the read() in a loop.In the >> native C function, the read is supposed to return a -1 upon timeout.But my >> driver >> does not support timeout.The default timeout value is zero and the linux >> select call upon zero time out causes an infinite wait.What am i >> missing...... >> >> > When I have tested RXTX between platforms, I have observed "hangup" inside > JNI driver when no data in Linux, is normal thing. > > Solution was setting the timeout for RXTX when no data from JNI driver. > > Something like that: > > commPort.enableReceiveTimeout(10); > > And it works perfect.... > > The only difference is that I am NOT using events - I am using continous > read in separate thread and if data is available, is parsed and transferred > to application using exception. > > Regards > Mariusz > > > >> Thanks and regards, >> Ravi >> >> Date: Wed, 3 Feb 2010 09:26:50 +0000 >> From: Michael Erskine >> To: "rxtx at qbang.org" >> Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? >> Message-ID: >> >> >> Content-Type: text/plain; charset="us-ascii" >> >> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >> Of >> > Ravishankar N >> > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? >> > >> > My serial port driver(apparently) does not support receive timeout.I >> > registered an event listener for DATA_AVAILABLE. However, the control >> never >> > seems to come out of the 'while' loop.Shouldn't the >> > InputStream.read return a '-1' immediately if no data is available (this >> seems >> > to be the default operation)? >> >> Your event handler should handle the event and return immediately so that >> its controlling thread can handle other events. I recommend a single read in >> the following manner: rawbuf is a byte[] of "reasonable" size and the >> read(byte[]) reads all available bytes up to the size of the buffer >> returning the number of bytes actually read... >> >> case SerialPortEvent.DATA_AVAILABLE: >> try { >> int i = is.read(rawbuf); >> if (i == -1) { >> << process EOF condition - should never happen >> >> return; >> } >> << process bytes (rawbuf, i); >> >> return; >> } catch (IOException e) { >> << promptly deal with exception >> >> return; >> } >> >> This style of reading has worked for me with RXTX on Linux and Windows XP >> for a good few years now in railway industry communications systems. Any >> timeouts (largely unnecessary in my applications) can be handled elsewhere, >> usually at a higher layer. >> >> Regards, >> Michael Erskine. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Feb 3 07:33:27 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:33:27 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: <73a89f361002030633j682610afia48dc7accd8e049b@mail.gmail.com> 2010/2/3 John Coffey > I'm guessing that this is driver specific. I recently had to support a > select()/poll() infrastructure for a linux serial DD, its certainly non > trivial to support async IO, so I suspect the problem in this case has to do > with missing poll infrastructure in the device driver. This also has to > coupled with special open flags for the device (which is within the rxtx > code) > > Yes, you are right, it may be driver specific, but in my case I haven't changed blocking JNI driver. I have added ONLY one call to RXTX method mentioned in my previous post and blocking (as seen as from Java app) gone out... Maybe this is not elegant, but works without problem in my app. I am using only FTDI chips and their drivers from couple of years and maybe this is the kind of the way to have no many problems with serial as well? Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From andyrxtx at g0poy.co.uk Wed Feb 3 11:09:04 2010 From: andyrxtx at g0poy.co.uk (andyrxtx at g0poy.co.uk) Date: Wed, 3 Feb 2010 18:09:04 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes Message-ID: <20100203180904.164f24dd@workstation.site> ?Hello RXTX group, I have just joined this group, and this is my first posting. I wanted to pass on some information regarding rxtx, so apologies if this has been brought up before. I have searched back through the archives but nothing specific came up. I am not a Java programmer, and I only came across rxtx a few days ago. I use a piece of test equipment called a miniVNA http://www.miniradiosolutions.com/ This is a serial USB controlled instrument, and it has control software available for MS windows, and a very old and now non-working Linux application. A few days ago Dietmar, DL2SBA released a Java application to control the miniVNA, obviously this application makes use of rxtx. The program worked fine on Windows, so I set about installing it onto Linux. I use SUSE11.1 After a few false starts, I got the system running fairly easily, sorting out the file locking by adding the uucp group to the users account as suggested (I used the 2.2pre binary files) I then passed the install instructions onto another miniVNA user, who also uses SUSE, but he ran into problems. To cut a long story short, he was also having file lock problems, but the uucp fix did not work. Digging into his system I found that there have been some changes in SUSE 11.2. tty ports are now assigned to the dialout group rather than uucp. A hint in the rxtx INSTALL file, suggested that var/lock needs to be checked, so: SUSE 11.1, var/lock is root:uucp SUSE 11.2 var/lock is root:root A search on Google brought up several comments regarding this, and also a bugzilla entry. https://bugzilla.novell.com/show_bug.cgi?id=552095 However from reading the various posts, some of which are in the bugzilla entry, it appears that many distros may be, or have changed to this configuration, and this will undoubtedly break several things, rxtx included. I solved my fellow SUSE users problem by compiling the rxtx libs with the no lock file option during configure, and that solved his problem. As this issue will probably take some time to get resolved across all the various Linux distros, it might be worth considering changing the default on the Linux build of rxtx not to use lockfiles, or provide the two versions of the lib in the binary archive. Thanks for your indulgence Andy From damorales at gmail.com Wed Feb 3 11:33:23 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 15:33:23 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203180904.164f24dd@workstation.site> References: <20100203180904.164f24dd@workstation.site> Message-ID: Hi I had the same problem in Mandriva 2010 and yes, adding the user to the uucp group did not work as it used to be in earlier versions of linux distros, causing RXTX to not work as non root user. The problem appears because the existense of UDEV, now you MUST add a RULE so the group (uucp or whatever) have access (Read, Write, Execute) to the Serial Port. To solve the problem, without needing to recompile RXTX, you must add a rule to grant permissions (0666) to the group for the device or port (tty*, ttyUSB*, etc). I do not remember now what is the line i added but when i come back home i will give it to you (i am at work now). Greetings ! 2010/2/3 > Hello RXTX group, > > I have just joined this group, and this is my first posting. > I wanted to pass on some information regarding rxtx, so apologies if > this has been brought up before. I have searched back through the > archives but nothing specific came up. > > I am not a Java programmer, and I only came across rxtx a few days ago. > > I use a piece of test equipment called a miniVNA > http://www.miniradiosolutions.com/ > > This is a serial USB controlled instrument, and it has control software > available for MS windows, and a very old and now non-working Linux > application. > > A few days ago Dietmar, DL2SBA released a Java application to control the > miniVNA, obviously this application makes use of rxtx. > > The program worked fine on Windows, so I set about installing it onto > Linux. I use SUSE11.1 After a few false starts, I got the system running > fairly easily, sorting out the file locking by adding the uucp group to > the users account as suggested (I used the 2.2pre binary files) I then > passed the install instructions onto another miniVNA user, who also uses > SUSE, but he ran into problems. To cut a long story short, he was > also having file lock problems, but the uucp fix did not work. Digging > into his system I found that there have been some changes in SUSE 11.2. > > tty ports are now assigned to the dialout group rather than uucp. > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > checked, so: > > SUSE 11.1, var/lock is root:uucp > SUSE 11.2 var/lock is root:root > > A search on Google brought up several comments regarding this, and also > a bugzilla entry. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > However from reading the various posts, some of which are in the bugzilla > entry, it appears that many distros may be, or have changed to this > configuration, and this will undoubtedly break several things, rxtx > included. > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > no lock file option during configure, and that solved his problem. > > As this issue will probably take some time to get resolved across all the > various Linux distros, it might be worth considering changing the default > on the Linux build of rxtx not to use lockfiles, or provide the two > versions of the lib in the binary archive. > > Thanks for your indulgence > > Andy > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Wed Feb 3 12:07:02 2010 From: andy at g0poy.com (Andy Eskelson) Date: Wed, 3 Feb 2010 19:07:02 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> Message-ID: <20100203190702.1b0e7015@workstation.site> Thanks Daniel, I am aware of the permissions problem, I have had a udev rules to solve this for other programs for some time. . I don't think that this is the same problem. as far as I can understand things, the lock files are written in var/lock. Previously var/lock and dev/tty-whatever were the same group. Now with var/lock owned by and with a group of root:root anything other than root cannot create a lock file. Even minicom is broken by this change. This change is going to have quite a few knock-on effects I think. Andy On Wed, 3 Feb 2010 15:33:23 -0300 Daniel Morales Salas wrote: > Hi > > I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > group did not work as it used to be in earlier versions of linux distros, > causing RXTX to not work as non root user. > > The problem appears because the existense of UDEV, now you MUST add a RULE > so the group (uucp or whatever) have access (Read, Write, Execute) to the > Serial Port. > > To solve the problem, without needing to recompile RXTX, you must add a rule > to grant permissions (0666) to the group for the device or port (tty*, > ttyUSB*, etc). I do not remember now what is the line i added but when i > come back home i will give it to you (i am at work now). > > Greetings ! > > 2010/2/3 > > > Hello RXTX group, > > > > I have just joined this group, and this is my first posting. > > I wanted to pass on some information regarding rxtx, so apologies if > > this has been brought up before. I have searched back through the > > archives but nothing specific came up. > > > > I am not a Java programmer, and I only came across rxtx a few days ago. > > > > I use a piece of test equipment called a miniVNA > > http://www.miniradiosolutions.com/ > > > > This is a serial USB controlled instrument, and it has control software > > available for MS windows, and a very old and now non-working Linux > > application. > > > > A few days ago Dietmar, DL2SBA released a Java application to control the > > miniVNA, obviously this application makes use of rxtx. > > > > The program worked fine on Windows, so I set about installing it onto > > Linux. I use SUSE11.1 After a few false starts, I got the system running > > fairly easily, sorting out the file locking by adding the uucp group to > > the users account as suggested (I used the 2.2pre binary files) I then > > passed the install instructions onto another miniVNA user, who also uses > > SUSE, but he ran into problems. To cut a long story short, he was > > also having file lock problems, but the uucp fix did not work. Digging > > into his system I found that there have been some changes in SUSE 11.2. > > > > tty ports are now assigned to the dialout group rather than uucp. > > > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > checked, so: > > > > SUSE 11.1, var/lock is root:uucp > > SUSE 11.2 var/lock is root:root > > > > A search on Google brought up several comments regarding this, and also > > a bugzilla entry. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > However from reading the various posts, some of which are in the bugzilla > > entry, it appears that many distros may be, or have changed to this > > configuration, and this will undoubtedly break several things, rxtx > > included. > > > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > > no lock file option during configure, and that solved his problem. > > > > As this issue will probably take some time to get resolved across all the > > various Linux distros, it might be worth considering changing the default > > on the Linux build of rxtx not to use lockfiles, or provide the two > > versions of the lib in the binary archive. > > > > Thanks for your indulgence > > > > Andy > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From thisdyingdream at gmail.com Wed Feb 3 12:32:35 2010 From: thisdyingdream at gmail.com (Steven Harms) Date: Wed, 3 Feb 2010 14:32:35 -0500 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203190702.1b0e7015@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: This is currently a bug in OpenSUSE that affects more than just rxtx, and is a result of unified udev rules. You can work around this by making udev change the group back to uucp until something more happens. https://bugzilla.novell.com/show_bug.cgi?id=552095 Thanks, Steve On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > Thanks Daniel, > > I am aware of the permissions problem, I have had a udev rules to solve > this for other programs for some time. > . > I don't think that this is the same problem. as far as I can understand > things, the lock files are written in var/lock. Previously var/lock and > dev/tty-whatever were the same group. Now with var/lock owned by and with > a group of root:root anything other than root cannot create a lock > file. Even minicom is broken by this change. > > This change is going to have quite a few knock-on effects I think. > > > Andy > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > Daniel Morales Salas wrote: > >> Hi >> >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp >> group did not work as it used to be in earlier versions of linux distros, >> causing RXTX to not work as non root user. >> >> The problem appears because the existense of UDEV, now you MUST add a RULE >> so the group (uucp or whatever) have access (Read, Write, Execute) to the >> Serial Port. >> >> To solve the problem, without needing to recompile RXTX, you must add a rule >> to grant permissions (0666) to the group for the device or port (tty*, >> ttyUSB*, etc). I do not remember now what is the line i added but when i >> come back home i will give it to you (i am at work now). >> >> Greetings ! >> >> 2010/2/3 >> >> > Hello RXTX group, >> > >> > I have just joined this group, and this is my first posting. >> > I wanted to pass on ?some information regarding rxtx, so apologies if >> > this has been brought up before. I have searched back through the >> > archives but nothing specific came up. >> > >> > I am not a Java programmer, and I only came across rxtx a few days ago. >> > >> > I use a piece of test equipment called a miniVNA >> > http://www.miniradiosolutions.com/ >> > >> > This is a serial USB controlled instrument, and it has control software >> > available for MS windows, and a very old and now non-working Linux >> > application. >> > >> > A few days ago Dietmar, DL2SBA released a Java application to control the >> > miniVNA, obviously this application makes use of rxtx. >> > >> > The program worked fine on Windows, so I set about installing it onto >> > Linux. I use SUSE11.1 After a few false starts, I got the system running >> > fairly easily, sorting out the file locking by adding the uucp group to >> > the users account as suggested (I used the 2.2pre binary files) I then >> > passed the install instructions onto another miniVNA user, who also uses >> > SUSE, but he ran into problems. To cut a long story short, he was >> > also having file lock problems, but the uucp fix did not work. Digging >> > into his system I found that there have been some changes in SUSE 11.2. >> > >> > tty ports are now assigned to the dialout group rather than uucp. >> > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be >> > checked, so: >> > >> > SUSE 11.1, var/lock is root:uucp >> > SUSE 11.2 var/lock is root:root >> > >> > A search on Google brought up several comments regarding this, and also >> > a ?bugzilla entry. >> > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 >> > >> > However from reading the various posts, some of which are in the bugzilla >> > entry, it appears that many distros may be, or have changed to this >> > configuration, and this will undoubtedly break several things, rxtx >> > included. >> > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the >> > no lock file option during configure, and that solved his problem. >> > >> > As this issue will probably take some time to get resolved across all the >> > various Linux distros, it might be worth considering changing the default >> > on the Linux build of rxtx not to use lockfiles, or provide the two >> > versions of the lib in the binary archive. >> > >> > Thanks for your indulgence >> > >> > Andy >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> >> >> >> -- >> Atte: >> Daniel Dario Morales Salas >> Ingeniero Civil en Computaci?n e Inform?tica >> Tel?fono: 02 684 3417 >> Celular: 09 643 1802 >> Santiago, Chile > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 WWW: http://www.sharms.org/blog From andy at g0poy.com Wed Feb 3 17:58:29 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 00:58:29 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: <20100204005829.7dc944e1@workstation.site> Thanks Steve, changing the serial ports back the uucp is not a big problem. I have a udev rule that can be easily modified already. However I cannot see any way of dealing with the var/lock problem apart from making it writable to all. Any thoughts? Andy On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms wrote: > This is currently a bug in OpenSUSE that affects more than just rxtx, > and is a result of unified udev rules. You can work around this by > making udev change the group back to uucp until something more > happens. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > Thanks, > > Steve > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > Thanks Daniel, > > > > I am aware of the permissions problem, I have had a udev rules to solve > > this for other programs for some time. > > . > > I don't think that this is the same problem. as far as I can understand > > things, the lock files are written in var/lock. Previously var/lock and > > dev/tty-whatever were the same group. Now with var/lock owned by and with > > a group of root:root anything other than root cannot create a lock > > file. Even minicom is broken by this change. > > > > This change is going to have quite a few knock-on effects I think. > > > > > > Andy > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > Daniel Morales Salas wrote: > > > >> Hi > >> > >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > >> group did not work as it used to be in earlier versions of linux distros, > >> causing RXTX to not work as non root user. > >> > >> The problem appears because the existense of UDEV, now you MUST add a RULE > >> so the group (uucp or whatever) have access (Read, Write, Execute) to the > >> Serial Port. > >> > >> To solve the problem, without needing to recompile RXTX, you must add a rule > >> to grant permissions (0666) to the group for the device or port (tty*, > >> ttyUSB*, etc). I do not remember now what is the line i added but when i > >> come back home i will give it to you (i am at work now). > >> > >> Greetings ! > >> > >> 2010/2/3 > >> > >> > Hello RXTX group, > >> > > >> > I have just joined this group, and this is my first posting. > >> > I wanted to pass on ?some information regarding rxtx, so apologies if > >> > this has been brought up before. I have searched back through the > >> > archives but nothing specific came up. > >> > > >> > I am not a Java programmer, and I only came across rxtx a few days ago. > >> > > >> > I use a piece of test equipment called a miniVNA > >> > http://www.miniradiosolutions.com/ > >> > > >> > This is a serial USB controlled instrument, and it has control software > >> > available for MS windows, and a very old and now non-working Linux > >> > application. > >> > > >> > A few days ago Dietmar, DL2SBA released a Java application to control the > >> > miniVNA, obviously this application makes use of rxtx. > >> > > >> > The program worked fine on Windows, so I set about installing it onto > >> > Linux. I use SUSE11.1 After a few false starts, I got the system running > >> > fairly easily, sorting out the file locking by adding the uucp group to > >> > the users account as suggested (I used the 2.2pre binary files) I then > >> > passed the install instructions onto another miniVNA user, who also uses > >> > SUSE, but he ran into problems. To cut a long story short, he was > >> > also having file lock problems, but the uucp fix did not work. Digging > >> > into his system I found that there have been some changes in SUSE 11.2. > >> > > >> > tty ports are now assigned to the dialout group rather than uucp. > >> > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > >> > checked, so: > >> > > >> > SUSE 11.1, var/lock is root:uucp > >> > SUSE 11.2 var/lock is root:root > >> > > >> > A search on Google brought up several comments regarding this, and also > >> > a ?bugzilla entry. > >> > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > >> > > >> > However from reading the various posts, some of which are in the bugzilla > >> > entry, it appears that many distros may be, or have changed to this > >> > configuration, and this will undoubtedly break several things, rxtx > >> > included. > >> > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the > >> > no lock file option during configure, and that solved his problem. > >> > > >> > As this issue will probably take some time to get resolved across all the > >> > various Linux distros, it might be worth considering changing the default > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > >> > versions of the lib in the binary archive. > >> > > >> > Thanks for your indulgence > >> > > >> > Andy > >> > > >> > _______________________________________________ > >> > Rxtx mailing list > >> > Rxtx at qbang.org > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > >> > >> > >> > >> -- > >> Atte: > >> Daniel Dario Morales Salas > >> Ingeniero Civil en Computaci?n e Inform?tica > >> Tel?fono: 02 684 3417 > >> Celular: 09 643 1802 > >> Santiago, Chile > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > WWW: http://www.sharms.org/blog From damorales at gmail.com Wed Feb 3 18:26:38 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 22:26:38 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100204005829.7dc944e1@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: Hello I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva 2010 this is what i get: drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ and i don't have ANY problem with lock files and RXTX in my java software. All i had to do was add this rule to udev: # serial KERNEL=="tty*", GROUP="uucp", MODE="0666" and that was all. Of course my user (metalklesk) is part of uucp group. I did not make /var/lock writable to all users. Greetings ! 2010/2/3 Andy Eskelson > Thanks Steve, > > changing the serial ports back the uucp is not a big problem. I have a > udev rule that can be easily modified already. However I cannot see any > way of dealing with the var/lock problem apart from making it writable to > all. Any thoughts? > > Andy > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > wrote: > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > and is a result of unified udev rules. You can work around this by > > making udev change the group back to uucp until something more > > happens. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > Thanks, > > > > Steve > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > Thanks Daniel, > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > this for other programs for some time. > > > . > > > I don't think that this is the same problem. as far as I can understand > > > things, the lock files are written in var/lock. Previously var/lock and > > > dev/tty-whatever were the same group. Now with var/lock owned by and > with > > > a group of root:root anything other than root cannot create a lock > > > file. Even minicom is broken by this change. > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > Daniel Morales Salas wrote: > > > > > >> Hi > > >> > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > the uucp > > >> group did not work as it used to be in earlier versions of linux > distros, > > >> causing RXTX to not work as non root user. > > >> > > >> The problem appears because the existense of UDEV, now you MUST add a > RULE > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > the > > >> Serial Port. > > >> > > >> To solve the problem, without needing to recompile RXTX, you must add > a rule > > >> to grant permissions (0666) to the group for the device or port (tty*, > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > i > > >> come back home i will give it to you (i am at work now). > > >> > > >> Greetings ! > > >> > > >> 2010/2/3 > > >> > > >> > Hello RXTX group, > > >> > > > >> > I have just joined this group, and this is my first posting. > > >> > I wanted to pass on some information regarding rxtx, so apologies > if > > >> > this has been brought up before. I have searched back through the > > >> > archives but nothing specific came up. > > >> > > > >> > I am not a Java programmer, and I only came across rxtx a few days > ago. > > >> > > > >> > I use a piece of test equipment called a miniVNA > > >> > http://www.miniradiosolutions.com/ > > >> > > > >> > This is a serial USB controlled instrument, and it has control > software > > >> > available for MS windows, and a very old and now non-working Linux > > >> > application. > > >> > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > control the > > >> > miniVNA, obviously this application makes use of rxtx. > > >> > > > >> > The program worked fine on Windows, so I set about installing it > onto > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > running > > >> > fairly easily, sorting out the file locking by adding the uucp group > to > > >> > the users account as suggested (I used the 2.2pre binary files) I > then > > >> > passed the install instructions onto another miniVNA user, who also > uses > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > >> > also having file lock problems, but the uucp fix did not work. > Digging > > >> > into his system I found that there have been some changes in SUSE > 11.2. > > >> > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > >> > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > >> > checked, so: > > >> > > > >> > SUSE 11.1, var/lock is root:uucp > > >> > SUSE 11.2 var/lock is root:root > > >> > > > >> > A search on Google brought up several comments regarding this, and > also > > >> > a bugzilla entry. > > >> > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > >> > > > >> > However from reading the various posts, some of which are in the > bugzilla > > >> > entry, it appears that many distros may be, or have changed to this > > >> > configuration, and this will undoubtedly break several things, rxtx > > >> > included. > > >> > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > with the > > >> > no lock file option during configure, and that solved his problem. > > >> > > > >> > As this issue will probably take some time to get resolved across > all the > > >> > various Linux distros, it might be worth considering changing the > default > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > >> > versions of the lib in the binary archive. > > >> > > > >> > Thanks for your indulgence > > >> > > > >> > Andy > > >> > > > >> > _______________________________________________ > > >> > Rxtx mailing list > > >> > Rxtx at qbang.org > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > >> > > > >> > > >> > > >> > > >> -- > > >> Atte: > > >> Daniel Dario Morales Salas > > >> Ingeniero Civil en Computaci?n e Inform?tica > > >> Tel?fono: 02 684 3417 > > >> Celular: 09 643 1802 > > >> Santiago, Chile > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at qbang.org > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > -- > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > WWW: http://www.sharms.org/blog > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Thu Feb 4 05:31:46 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 12:31:46 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: <20100204123146.6cffeb67@workstation.site> Thank's for the confirmation. Something odd is going on somewhere in SUSE 11.2. I'll have to build up a local SUSE11.2 system to see if I can nail down exactly what is going on. Something is blocking the lockfiles in var/lock. The net is nice, but it's a bit difficult trying to work out what is going on what the machine in question is in Germany and I'm in the UK :-) Andy On Wed, 3 Feb 2010 22:26:38 -0300 Daniel Morales Salas wrote: > Hello > > I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva > 2010 this is what i get: > > drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ > > and i don't have ANY problem with lock files and RXTX in my java software. > All i had to do was add this rule to udev: > > # serial > KERNEL=="tty*", GROUP="uucp", MODE="0666" > > and that was all. Of course my user (metalklesk) is part of uucp group. > I did not make /var/lock writable to all users. > > Greetings ! > > 2010/2/3 Andy Eskelson > > > Thanks Steve, > > > > changing the serial ports back the uucp is not a big problem. I have a > > udev rule that can be easily modified already. However I cannot see any > > way of dealing with the var/lock problem apart from making it writable to > > all. Any thoughts? > > > > Andy > > > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > > wrote: > > > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > > and is a result of unified udev rules. You can work around this by > > > making udev change the group back to uucp until something more > > > happens. > > > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > > > Thanks, > > > > > > Steve > > > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > > Thanks Daniel, > > > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > > this for other programs for some time. > > > > . > > > > I don't think that this is the same problem. as far as I can understand > > > > things, the lock files are written in var/lock. Previously var/lock and > > > > dev/tty-whatever were the same group. Now with var/lock owned by and > > with > > > > a group of root:root anything other than root cannot create a lock > > > > file. Even minicom is broken by this change. > > > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > > Daniel Morales Salas wrote: > > > > > > > >> Hi > > > >> > > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > > the uucp > > > >> group did not work as it used to be in earlier versions of linux > > distros, > > > >> causing RXTX to not work as non root user. > > > >> > > > >> The problem appears because the existense of UDEV, now you MUST add a > > RULE > > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > > the > > > >> Serial Port. > > > >> > > > >> To solve the problem, without needing to recompile RXTX, you must add > > a rule > > > >> to grant permissions (0666) to the group for the device or port (tty*, > > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > > i > > > >> come back home i will give it to you (i am at work now). > > > >> > > > >> Greetings ! > > > >> > > > >> 2010/2/3 > > > >> > > > >> > Hello RXTX group, > > > >> > > > > >> > I have just joined this group, and this is my first posting. > > > >> > I wanted to pass on some information regarding rxtx, so apologies > > if > > > >> > this has been brought up before. I have searched back through the > > > >> > archives but nothing specific came up. > > > >> > > > > >> > I am not a Java programmer, and I only came across rxtx a few days > > ago. > > > >> > > > > >> > I use a piece of test equipment called a miniVNA > > > >> > http://www.miniradiosolutions.com/ > > > >> > > > > >> > This is a serial USB controlled instrument, and it has control > > software > > > >> > available for MS windows, and a very old and now non-working Linux > > > >> > application. > > > >> > > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > > control the > > > >> > miniVNA, obviously this application makes use of rxtx. > > > >> > > > > >> > The program worked fine on Windows, so I set about installing it > > onto > > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > > running > > > >> > fairly easily, sorting out the file locking by adding the uucp group > > to > > > >> > the users account as suggested (I used the 2.2pre binary files) I > > then > > > >> > passed the install instructions onto another miniVNA user, who also > > uses > > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > > >> > also having file lock problems, but the uucp fix did not work. > > Digging > > > >> > into his system I found that there have been some changes in SUSE > > 11.2. > > > >> > > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > > >> > > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > > >> > checked, so: > > > >> > > > > >> > SUSE 11.1, var/lock is root:uucp > > > >> > SUSE 11.2 var/lock is root:root > > > >> > > > > >> > A search on Google brought up several comments regarding this, and > > also > > > >> > a bugzilla entry. > > > >> > > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > >> > > > > >> > However from reading the various posts, some of which are in the > > bugzilla > > > >> > entry, it appears that many distros may be, or have changed to this > > > >> > configuration, and this will undoubtedly break several things, rxtx > > > >> > included. > > > >> > > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > > with the > > > >> > no lock file option during configure, and that solved his problem. > > > >> > > > > >> > As this issue will probably take some time to get resolved across > > all the > > > >> > various Linux distros, it might be worth considering changing the > > default > > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > > >> > versions of the lib in the binary archive. > > > >> > > > > >> > Thanks for your indulgence > > > >> > > > > >> > Andy > > > >> > > > > >> > _______________________________________________ > > > >> > Rxtx mailing list > > > >> > Rxtx at qbang.org > > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > > >> > > > > >> > > > >> > > > >> > > > >> -- > > > >> Atte: > > > >> Daniel Dario Morales Salas > > > >> Ingeniero Civil en Computaci?n e Inform?tica > > > >> Tel?fono: 02 684 3417 > > > >> Celular: 09 643 1802 > > > >> Santiago, Chile > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at qbang.org > > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > > > -- > > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > > > WWW: http://www.sharms.org/blog > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 01:02:21 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 13:32:21 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> My serial port driver(apparently) does not support receive timeout.I registered an event listener for DATA_AVAILABLE. However, the control never seems to come out of the 'while' loop.Shouldn't the InputStream.read return a '-1' immediately if no data is available (this seems to be the default operation)? This was tried on a x86 Linux desktop using rxtx-2.1-7 I've added the snippet for clarity: /******************************************************************************************************************************************************************************/ mySerialPort.enableReceiveThreshold(2000);//Trying to set a time limit for read calls System.out.println(mySerialPort.isReceiveTimeoutEnabled()); // I get FALSE, so its not supported on hardware. mySerialPort.addEventListener(this); mySerialPort.notifyOnDataAvailable(true);//register a event with //my SerialEvent listener implementation: public void serialEvent(SerialPortEvent arg0) { int newData=0; switch(arg0.getEventType()){ case SerialPortEvent.DATA_AVAILABLE: while (newData != -1) { try { newData = is.read();//This should eventually return a -1 if no data is available within a timeout.PROBLEM!! System.out.println("Got a byte from port:"+newData); if (newData == -1) { break; } } catch (IOException ex) { System.err.println(ex); return; } } break; } return; } /******************************************************************************************************************************************************************************/ Thanks and regards, Ravi From michael.erskine at ketech.com Wed Feb 3 02:26:50 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 09:26:50 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From michael.erskine at ketech.com Wed Feb 3 05:03:30 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 12:03:30 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > Michael Erskine > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > > Your event handler should handle the event and return immediately so that its > controlling thread can handle other events. I recommend a single read in the > following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) > reads all available bytes up to the size of the buffer returning the number of > bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } After posting this I considered the glaring possibility of the rawbuf read buffer being too small to receive all the available bytes and perhaps skipping data: after all, I'm guessing that is why we see so many posts asking for help with blocking implementations of read event handlers looping on "while(bytes are available)". I've spent this morning writing an extensive multi-threaded unit test suite that includes tests with a tiny buffer compared to the amount of data available and found that no data was being skipped. I now want to know why! The SerialPortEvent.DATA_AVAILABLE event must be being fired again if there is more data available on the input stream. If that is the case then it should be heavily documented with good examples in the wiki to avoid the types of developer anguish we see so regularly. BTW: I'm not at liberty to post the JUnit tests as they use my company's unit test suite framework. Regards, Michael Erskine. From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 06:18:04 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 18:48:04 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Hello Michael, I tried out your suggestion but the problem is that the read(rawbuf) blocks until the entire length of the rawbuf array has been read (blocking). I cannot decide on a reasonable size of the array because it varies from 2 bytes to as much as 50 byes (i'm communicating with a modem,each response is of a different length), which is why i wanted to use non blocking calls. But on a side note, read(byte[]) in turn calls the read() in a loop.In the native C function, the read is supposed to return a -1 upon timeout.But my driver does not support timeout.The default timeout value is zero and the linux select call upon zero time out causes an infinite wait.What am i missing...... Thanks and regards, Ravi Date: Wed, 3 Feb 2010 09:26:50 +0000 From: Michael Erskine To: "rxtx at qbang.org" Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: Content-Type: text/plain; charset="us-ascii" > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From m.kirkland at comcast.net Wed Feb 3 06:46:03 2010 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 3 Feb 2010 05:46:03 -0800 Subject: [Rxtx] One port blocking another port In-Reply-To: References: Message-ID: <68768633814F4D7D86761D34F0764FE0@bengal.net> It turns out this is caused by having the RTS/CTS flow control turned on and me not providing a true on the RTS pin. Somehow it seems the port timing out on a read allows the write to proceed. This is not an issue for my application but I wonder if the write should not proceed until the RTS pin is true even if a read times out. mk -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Monday, January 25, 2010 7:48 PM To: Mike Kirkland Cc: rxtx at qbang.org Subject: Re: [Rxtx] One port blocking another port On Mon, 25 Jan 2010, Mike Kirkland wrote: > > Hi All, > > ? > > I have a program that reads from one com port and writes to another com > port. It also does the same thing in reverse (reads from the second com port > and writes to the first one. It basically ties two com ports together. > > ? > > One port is very chatty and has a consent stream of data. The other port has > very little data. > > ? > > Both ports use a 5000 ms (5 second) time out. > > ? > > The issue I am having is that is appears that the first port?s write to the > second port is blocked while the second port is waiting for input. The first > port?s write proceeds only after the second port has timed out. > > ? > > I suppose I could have something twisted around in my code but I was > wondering if this is a know issue? > Hi Kirk, I've not seen a report like this. Perhaps some simple reproduction code will reveal a problem on your end or help us identify a problem in rxtx. I think there are several users doing multiport communication. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Wed Feb 3 07:03:58 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:03:58 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Message-ID: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> 2010/2/3 Ravishankar N > Hello Michael, > [..] > But on a side note, read(byte[]) in turn calls the read() in a loop.In the > native C function, the read is supposed to return a -1 upon timeout.But my > driver > does not support timeout.The default timeout value is zero and the linux > select call upon zero time out causes an infinite wait.What am i > missing...... > > When I have tested RXTX between platforms, I have observed "hangup" inside JNI driver when no data in Linux, is normal thing. Solution was setting the timeout for RXTX when no data from JNI driver. Something like that: commPort.enableReceiveTimeout(10); And it works perfect.... The only difference is that I am NOT using events - I am using continous read in separate thread and if data is available, is parsed and transferred to application using exception. Regards Mariusz > Thanks and regards, > Ravi > > Date: Wed, 3 Feb 2010 09:26:50 +0000 > From: Michael Erskine > To: "rxtx at qbang.org" > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > Message-ID: > > > Content-Type: text/plain; charset="us-ascii" > > > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of > > Ravishankar N > > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > > > My serial port driver(apparently) does not support receive timeout.I > > registered an event listener for DATA_AVAILABLE. However, the control > never > > seems to come out of the 'while' loop.Shouldn't the > > InputStream.read return a '-1' immediately if no data is available (this > seems > > to be the default operation)? > > Your event handler should handle the event and return immediately so that > its controlling thread can handle other events. I recommend a single read in > the following manner: rawbuf is a byte[] of "reasonable" size and the > read(byte[]) reads all available bytes up to the size of the buffer > returning the number of bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } > > This style of reading has worked for me with RXTX on Linux and Windows XP > for a good few years now in railway industry communications systems. Any > timeouts (largely unnecessary in my applications) can be handled elsewhere, > usually at a higher layer. > > Regards, > Michael Erskine. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Feb 3 07:22:55 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 3 Feb 2010 09:22:55 -0500 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: I'm guessing that this is driver specific. I recently had to support a select()/poll() infrastructure for a linux serial DD, its certainly non trivial to support async IO, so I suspect the problem in this case has to do with missing poll infrastructure in the device driver. This also has to coupled with special open flags for the device (which is within the rxtx code) The key routines within a 2.6 kernel linux device driver are shown below (if you have access to it for your particular device) are indicated below (here is a snippet from my device driver c code that supports polling/select). User space code to test this shown below also, note that the device needs to be opened with the O_NONBLOCK option to support the select/poll api // device driver code ..... /* * File operations supported by this driver. */ static struct file_operations iop_fops = { .owner = THIS_MODULE, .check_flags= iop_check_flags, .ioctl = iop_ioctl, .open = iop_open, .poll = iop_poll, // SUPPORT FOR SELECT/POLL infrastructure .read = iop_read, .release = iop_release, .write = iop_write, }; /** * Select/poll/epoll infrastructure. * * @param file * @param wait * * @return */ static unsigned int iop_poll(struct file *filp, poll_table *wait) { struct iop_device *devp = (struct iop_device *)filp->private_data; // the poll_table wait arg is an opaque pointer poll_wait(filp, &devp->readq, wait); // return from poll indicating whether we have read/write data unsigned int mask = 0; if (kfifo_len(devp->rx_fifo)) { mask |= (POLLIN | POLLRDNORM); } // @JC We don't do select on write yet // if (kfifo_len(devp->tx_fifo)) { // mask |= (POLLOUT | POLLWRNORM); // } // Only print out while debugging // if (mask != 0) { // printk (KERN_INFO "%s: [%04x]\n", __FUNCTION__, mask); // } return mask; } /** * device driver blocking and non blocking read function. This * function reads the requested number of bytes from the read * kfifo blocking as required. * * @param filp * @param buf * @param count * @param f_pos * * @return */ static ssize_t iop_read(struct file *filp, char __user *buf, size_t count, loff_t * ppos) { // access appropriate device struct struct iop_device *devp = (struct iop_device *) filp->private_data; ssize_t retval; // support non blocking mode (default) by checking if the kfifo is empty first if ((kfifo_len(devp->rx_fifo)==0) && (filp->f_flags & O_NONBLOCK)) { return -EAGAIN; } // wait for rx_fifo to receive data via receive interrupts retval = wait_event_interruptible(devp->readq, kfifo_len(devp->rx_fifo) != 0); // check for some error condition if (retval) { printk (KERN_ERR "%s: wait_event_interruptible returned[%d]\n", __FUNCTION__, retval); return retval; } // copy max requested bytes from rx_fifo to device buffer // this may still leave bytes in the kfifo for a subsequent read // if we are reading in a loop retval = kfifo_get(devp->rx_fifo, devp->rxbuf, count); // printk (KERN_INFO "%s: [%d] byte(s)\n", __FUNCTION__, retval); if (copy_to_user(buf, devp->rxbuf, retval)) { printk (KERN_ERR "%s: problem copying rx_fifo data to user buffer\n", __FUNCTION__); return -EFAULT; } return retval; } // a selection of my user space code reading via select()/poll()..... // user space open code iop_fd = ::open( deviceName.data(), O_RDWR | O_NONBLOCK); while ((bytes_to_expect - bytes_read) > 0) { // must reinitialize these between select calls fd_set readfds; FD_ZERO( &readfds ); FD_SET( iop_fd, &readfds ); // 1s sec read polling timeout struct timeval timeout; timeout.tv_sec = 1; timeout.tv_usec = 0; int rc = select( FD_SETSIZE, &readfds, NULL, NULL, &timeout ); // read from file when descriptor // indicates data available without blocking if ((rc > 0) && FD_ISSET(iop_fd, &readfds)) { // read into the appropriate offset within the rx_buf int temp = read(iop_fd, rx_buf + bytes_read, bytes_to_expect - bytes_read); if (!temp) { printf("EOF detected with %d bytes expected\n", bytes_to_expect - bytes_read); } else { bytes_read += temp; } } else if (rc < 0){ printf("%s: select on [%s], bytes_read[%d], errno=%d\n", __FUNCTION__, thread_args->device, bytes_read, errno); } else { printf("%s: select on [%s], bytes_read[%d], timeout\n", __FUNCTION__, thread_args->device, bytes_read); } } On Wed, Feb 3, 2010 at 9:03 AM, Mariusz Dec wrote: > > > 2010/2/3 Ravishankar N > >> Hello Michael, >> [..] >> >> But on a side note, read(byte[]) in turn calls the read() in a loop.In the >> native C function, the read is supposed to return a -1 upon timeout.But my >> driver >> does not support timeout.The default timeout value is zero and the linux >> select call upon zero time out causes an infinite wait.What am i >> missing...... >> >> > When I have tested RXTX between platforms, I have observed "hangup" inside > JNI driver when no data in Linux, is normal thing. > > Solution was setting the timeout for RXTX when no data from JNI driver. > > Something like that: > > commPort.enableReceiveTimeout(10); > > And it works perfect.... > > The only difference is that I am NOT using events - I am using continous > read in separate thread and if data is available, is parsed and transferred > to application using exception. > > Regards > Mariusz > > > >> Thanks and regards, >> Ravi >> >> Date: Wed, 3 Feb 2010 09:26:50 +0000 >> From: Michael Erskine >> To: "rxtx at qbang.org" >> Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? >> Message-ID: >> >> >> Content-Type: text/plain; charset="us-ascii" >> >> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >> Of >> > Ravishankar N >> > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? >> > >> > My serial port driver(apparently) does not support receive timeout.I >> > registered an event listener for DATA_AVAILABLE. However, the control >> never >> > seems to come out of the 'while' loop.Shouldn't the >> > InputStream.read return a '-1' immediately if no data is available (this >> seems >> > to be the default operation)? >> >> Your event handler should handle the event and return immediately so that >> its controlling thread can handle other events. I recommend a single read in >> the following manner: rawbuf is a byte[] of "reasonable" size and the >> read(byte[]) reads all available bytes up to the size of the buffer >> returning the number of bytes actually read... >> >> case SerialPortEvent.DATA_AVAILABLE: >> try { >> int i = is.read(rawbuf); >> if (i == -1) { >> << process EOF condition - should never happen >> >> return; >> } >> << process bytes (rawbuf, i); >> >> return; >> } catch (IOException e) { >> << promptly deal with exception >> >> return; >> } >> >> This style of reading has worked for me with RXTX on Linux and Windows XP >> for a good few years now in railway industry communications systems. Any >> timeouts (largely unnecessary in my applications) can be handled elsewhere, >> usually at a higher layer. >> >> Regards, >> Michael Erskine. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Feb 3 07:33:27 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:33:27 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: <73a89f361002030633j682610afia48dc7accd8e049b@mail.gmail.com> 2010/2/3 John Coffey > I'm guessing that this is driver specific. I recently had to support a > select()/poll() infrastructure for a linux serial DD, its certainly non > trivial to support async IO, so I suspect the problem in this case has to do > with missing poll infrastructure in the device driver. This also has to > coupled with special open flags for the device (which is within the rxtx > code) > > Yes, you are right, it may be driver specific, but in my case I haven't changed blocking JNI driver. I have added ONLY one call to RXTX method mentioned in my previous post and blocking (as seen as from Java app) gone out... Maybe this is not elegant, but works without problem in my app. I am using only FTDI chips and their drivers from couple of years and maybe this is the kind of the way to have no many problems with serial as well? Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From andyrxtx at g0poy.co.uk Wed Feb 3 11:09:04 2010 From: andyrxtx at g0poy.co.uk (andyrxtx at g0poy.co.uk) Date: Wed, 3 Feb 2010 18:09:04 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes Message-ID: <20100203180904.164f24dd@workstation.site> ?Hello RXTX group, I have just joined this group, and this is my first posting. I wanted to pass on some information regarding rxtx, so apologies if this has been brought up before. I have searched back through the archives but nothing specific came up. I am not a Java programmer, and I only came across rxtx a few days ago. I use a piece of test equipment called a miniVNA http://www.miniradiosolutions.com/ This is a serial USB controlled instrument, and it has control software available for MS windows, and a very old and now non-working Linux application. A few days ago Dietmar, DL2SBA released a Java application to control the miniVNA, obviously this application makes use of rxtx. The program worked fine on Windows, so I set about installing it onto Linux. I use SUSE11.1 After a few false starts, I got the system running fairly easily, sorting out the file locking by adding the uucp group to the users account as suggested (I used the 2.2pre binary files) I then passed the install instructions onto another miniVNA user, who also uses SUSE, but he ran into problems. To cut a long story short, he was also having file lock problems, but the uucp fix did not work. Digging into his system I found that there have been some changes in SUSE 11.2. tty ports are now assigned to the dialout group rather than uucp. A hint in the rxtx INSTALL file, suggested that var/lock needs to be checked, so: SUSE 11.1, var/lock is root:uucp SUSE 11.2 var/lock is root:root A search on Google brought up several comments regarding this, and also a bugzilla entry. https://bugzilla.novell.com/show_bug.cgi?id=552095 However from reading the various posts, some of which are in the bugzilla entry, it appears that many distros may be, or have changed to this configuration, and this will undoubtedly break several things, rxtx included. I solved my fellow SUSE users problem by compiling the rxtx libs with the no lock file option during configure, and that solved his problem. As this issue will probably take some time to get resolved across all the various Linux distros, it might be worth considering changing the default on the Linux build of rxtx not to use lockfiles, or provide the two versions of the lib in the binary archive. Thanks for your indulgence Andy From damorales at gmail.com Wed Feb 3 11:33:23 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 15:33:23 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203180904.164f24dd@workstation.site> References: <20100203180904.164f24dd@workstation.site> Message-ID: Hi I had the same problem in Mandriva 2010 and yes, adding the user to the uucp group did not work as it used to be in earlier versions of linux distros, causing RXTX to not work as non root user. The problem appears because the existense of UDEV, now you MUST add a RULE so the group (uucp or whatever) have access (Read, Write, Execute) to the Serial Port. To solve the problem, without needing to recompile RXTX, you must add a rule to grant permissions (0666) to the group for the device or port (tty*, ttyUSB*, etc). I do not remember now what is the line i added but when i come back home i will give it to you (i am at work now). Greetings ! 2010/2/3 > Hello RXTX group, > > I have just joined this group, and this is my first posting. > I wanted to pass on some information regarding rxtx, so apologies if > this has been brought up before. I have searched back through the > archives but nothing specific came up. > > I am not a Java programmer, and I only came across rxtx a few days ago. > > I use a piece of test equipment called a miniVNA > http://www.miniradiosolutions.com/ > > This is a serial USB controlled instrument, and it has control software > available for MS windows, and a very old and now non-working Linux > application. > > A few days ago Dietmar, DL2SBA released a Java application to control the > miniVNA, obviously this application makes use of rxtx. > > The program worked fine on Windows, so I set about installing it onto > Linux. I use SUSE11.1 After a few false starts, I got the system running > fairly easily, sorting out the file locking by adding the uucp group to > the users account as suggested (I used the 2.2pre binary files) I then > passed the install instructions onto another miniVNA user, who also uses > SUSE, but he ran into problems. To cut a long story short, he was > also having file lock problems, but the uucp fix did not work. Digging > into his system I found that there have been some changes in SUSE 11.2. > > tty ports are now assigned to the dialout group rather than uucp. > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > checked, so: > > SUSE 11.1, var/lock is root:uucp > SUSE 11.2 var/lock is root:root > > A search on Google brought up several comments regarding this, and also > a bugzilla entry. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > However from reading the various posts, some of which are in the bugzilla > entry, it appears that many distros may be, or have changed to this > configuration, and this will undoubtedly break several things, rxtx > included. > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > no lock file option during configure, and that solved his problem. > > As this issue will probably take some time to get resolved across all the > various Linux distros, it might be worth considering changing the default > on the Linux build of rxtx not to use lockfiles, or provide the two > versions of the lib in the binary archive. > > Thanks for your indulgence > > Andy > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Wed Feb 3 12:07:02 2010 From: andy at g0poy.com (Andy Eskelson) Date: Wed, 3 Feb 2010 19:07:02 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> Message-ID: <20100203190702.1b0e7015@workstation.site> Thanks Daniel, I am aware of the permissions problem, I have had a udev rules to solve this for other programs for some time. . I don't think that this is the same problem. as far as I can understand things, the lock files are written in var/lock. Previously var/lock and dev/tty-whatever were the same group. Now with var/lock owned by and with a group of root:root anything other than root cannot create a lock file. Even minicom is broken by this change. This change is going to have quite a few knock-on effects I think. Andy On Wed, 3 Feb 2010 15:33:23 -0300 Daniel Morales Salas wrote: > Hi > > I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > group did not work as it used to be in earlier versions of linux distros, > causing RXTX to not work as non root user. > > The problem appears because the existense of UDEV, now you MUST add a RULE > so the group (uucp or whatever) have access (Read, Write, Execute) to the > Serial Port. > > To solve the problem, without needing to recompile RXTX, you must add a rule > to grant permissions (0666) to the group for the device or port (tty*, > ttyUSB*, etc). I do not remember now what is the line i added but when i > come back home i will give it to you (i am at work now). > > Greetings ! > > 2010/2/3 > > > Hello RXTX group, > > > > I have just joined this group, and this is my first posting. > > I wanted to pass on some information regarding rxtx, so apologies if > > this has been brought up before. I have searched back through the > > archives but nothing specific came up. > > > > I am not a Java programmer, and I only came across rxtx a few days ago. > > > > I use a piece of test equipment called a miniVNA > > http://www.miniradiosolutions.com/ > > > > This is a serial USB controlled instrument, and it has control software > > available for MS windows, and a very old and now non-working Linux > > application. > > > > A few days ago Dietmar, DL2SBA released a Java application to control the > > miniVNA, obviously this application makes use of rxtx. > > > > The program worked fine on Windows, so I set about installing it onto > > Linux. I use SUSE11.1 After a few false starts, I got the system running > > fairly easily, sorting out the file locking by adding the uucp group to > > the users account as suggested (I used the 2.2pre binary files) I then > > passed the install instructions onto another miniVNA user, who also uses > > SUSE, but he ran into problems. To cut a long story short, he was > > also having file lock problems, but the uucp fix did not work. Digging > > into his system I found that there have been some changes in SUSE 11.2. > > > > tty ports are now assigned to the dialout group rather than uucp. > > > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > checked, so: > > > > SUSE 11.1, var/lock is root:uucp > > SUSE 11.2 var/lock is root:root > > > > A search on Google brought up several comments regarding this, and also > > a bugzilla entry. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > However from reading the various posts, some of which are in the bugzilla > > entry, it appears that many distros may be, or have changed to this > > configuration, and this will undoubtedly break several things, rxtx > > included. > > > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > > no lock file option during configure, and that solved his problem. > > > > As this issue will probably take some time to get resolved across all the > > various Linux distros, it might be worth considering changing the default > > on the Linux build of rxtx not to use lockfiles, or provide the two > > versions of the lib in the binary archive. > > > > Thanks for your indulgence > > > > Andy > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From thisdyingdream at gmail.com Wed Feb 3 12:32:35 2010 From: thisdyingdream at gmail.com (Steven Harms) Date: Wed, 3 Feb 2010 14:32:35 -0500 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203190702.1b0e7015@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: This is currently a bug in OpenSUSE that affects more than just rxtx, and is a result of unified udev rules. You can work around this by making udev change the group back to uucp until something more happens. https://bugzilla.novell.com/show_bug.cgi?id=552095 Thanks, Steve On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > Thanks Daniel, > > I am aware of the permissions problem, I have had a udev rules to solve > this for other programs for some time. > . > I don't think that this is the same problem. as far as I can understand > things, the lock files are written in var/lock. Previously var/lock and > dev/tty-whatever were the same group. Now with var/lock owned by and with > a group of root:root anything other than root cannot create a lock > file. Even minicom is broken by this change. > > This change is going to have quite a few knock-on effects I think. > > > Andy > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > Daniel Morales Salas wrote: > >> Hi >> >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp >> group did not work as it used to be in earlier versions of linux distros, >> causing RXTX to not work as non root user. >> >> The problem appears because the existense of UDEV, now you MUST add a RULE >> so the group (uucp or whatever) have access (Read, Write, Execute) to the >> Serial Port. >> >> To solve the problem, without needing to recompile RXTX, you must add a rule >> to grant permissions (0666) to the group for the device or port (tty*, >> ttyUSB*, etc). I do not remember now what is the line i added but when i >> come back home i will give it to you (i am at work now). >> >> Greetings ! >> >> 2010/2/3 >> >> > Hello RXTX group, >> > >> > I have just joined this group, and this is my first posting. >> > I wanted to pass on ?some information regarding rxtx, so apologies if >> > this has been brought up before. I have searched back through the >> > archives but nothing specific came up. >> > >> > I am not a Java programmer, and I only came across rxtx a few days ago. >> > >> > I use a piece of test equipment called a miniVNA >> > http://www.miniradiosolutions.com/ >> > >> > This is a serial USB controlled instrument, and it has control software >> > available for MS windows, and a very old and now non-working Linux >> > application. >> > >> > A few days ago Dietmar, DL2SBA released a Java application to control the >> > miniVNA, obviously this application makes use of rxtx. >> > >> > The program worked fine on Windows, so I set about installing it onto >> > Linux. I use SUSE11.1 After a few false starts, I got the system running >> > fairly easily, sorting out the file locking by adding the uucp group to >> > the users account as suggested (I used the 2.2pre binary files) I then >> > passed the install instructions onto another miniVNA user, who also uses >> > SUSE, but he ran into problems. To cut a long story short, he was >> > also having file lock problems, but the uucp fix did not work. Digging >> > into his system I found that there have been some changes in SUSE 11.2. >> > >> > tty ports are now assigned to the dialout group rather than uucp. >> > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be >> > checked, so: >> > >> > SUSE 11.1, var/lock is root:uucp >> > SUSE 11.2 var/lock is root:root >> > >> > A search on Google brought up several comments regarding this, and also >> > a ?bugzilla entry. >> > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 >> > >> > However from reading the various posts, some of which are in the bugzilla >> > entry, it appears that many distros may be, or have changed to this >> > configuration, and this will undoubtedly break several things, rxtx >> > included. >> > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the >> > no lock file option during configure, and that solved his problem. >> > >> > As this issue will probably take some time to get resolved across all the >> > various Linux distros, it might be worth considering changing the default >> > on the Linux build of rxtx not to use lockfiles, or provide the two >> > versions of the lib in the binary archive. >> > >> > Thanks for your indulgence >> > >> > Andy >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> >> >> >> -- >> Atte: >> Daniel Dario Morales Salas >> Ingeniero Civil en Computaci?n e Inform?tica >> Tel?fono: 02 684 3417 >> Celular: 09 643 1802 >> Santiago, Chile > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 WWW: http://www.sharms.org/blog From andy at g0poy.com Wed Feb 3 17:58:29 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 00:58:29 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: <20100204005829.7dc944e1@workstation.site> Thanks Steve, changing the serial ports back the uucp is not a big problem. I have a udev rule that can be easily modified already. However I cannot see any way of dealing with the var/lock problem apart from making it writable to all. Any thoughts? Andy On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms wrote: > This is currently a bug in OpenSUSE that affects more than just rxtx, > and is a result of unified udev rules. You can work around this by > making udev change the group back to uucp until something more > happens. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > Thanks, > > Steve > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > Thanks Daniel, > > > > I am aware of the permissions problem, I have had a udev rules to solve > > this for other programs for some time. > > . > > I don't think that this is the same problem. as far as I can understand > > things, the lock files are written in var/lock. Previously var/lock and > > dev/tty-whatever were the same group. Now with var/lock owned by and with > > a group of root:root anything other than root cannot create a lock > > file. Even minicom is broken by this change. > > > > This change is going to have quite a few knock-on effects I think. > > > > > > Andy > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > Daniel Morales Salas wrote: > > > >> Hi > >> > >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > >> group did not work as it used to be in earlier versions of linux distros, > >> causing RXTX to not work as non root user. > >> > >> The problem appears because the existense of UDEV, now you MUST add a RULE > >> so the group (uucp or whatever) have access (Read, Write, Execute) to the > >> Serial Port. > >> > >> To solve the problem, without needing to recompile RXTX, you must add a rule > >> to grant permissions (0666) to the group for the device or port (tty*, > >> ttyUSB*, etc). I do not remember now what is the line i added but when i > >> come back home i will give it to you (i am at work now). > >> > >> Greetings ! > >> > >> 2010/2/3 > >> > >> > Hello RXTX group, > >> > > >> > I have just joined this group, and this is my first posting. > >> > I wanted to pass on ?some information regarding rxtx, so apologies if > >> > this has been brought up before. I have searched back through the > >> > archives but nothing specific came up. > >> > > >> > I am not a Java programmer, and I only came across rxtx a few days ago. > >> > > >> > I use a piece of test equipment called a miniVNA > >> > http://www.miniradiosolutions.com/ > >> > > >> > This is a serial USB controlled instrument, and it has control software > >> > available for MS windows, and a very old and now non-working Linux > >> > application. > >> > > >> > A few days ago Dietmar, DL2SBA released a Java application to control the > >> > miniVNA, obviously this application makes use of rxtx. > >> > > >> > The program worked fine on Windows, so I set about installing it onto > >> > Linux. I use SUSE11.1 After a few false starts, I got the system running > >> > fairly easily, sorting out the file locking by adding the uucp group to > >> > the users account as suggested (I used the 2.2pre binary files) I then > >> > passed the install instructions onto another miniVNA user, who also uses > >> > SUSE, but he ran into problems. To cut a long story short, he was > >> > also having file lock problems, but the uucp fix did not work. Digging > >> > into his system I found that there have been some changes in SUSE 11.2. > >> > > >> > tty ports are now assigned to the dialout group rather than uucp. > >> > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > >> > checked, so: > >> > > >> > SUSE 11.1, var/lock is root:uucp > >> > SUSE 11.2 var/lock is root:root > >> > > >> > A search on Google brought up several comments regarding this, and also > >> > a ?bugzilla entry. > >> > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > >> > > >> > However from reading the various posts, some of which are in the bugzilla > >> > entry, it appears that many distros may be, or have changed to this > >> > configuration, and this will undoubtedly break several things, rxtx > >> > included. > >> > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the > >> > no lock file option during configure, and that solved his problem. > >> > > >> > As this issue will probably take some time to get resolved across all the > >> > various Linux distros, it might be worth considering changing the default > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > >> > versions of the lib in the binary archive. > >> > > >> > Thanks for your indulgence > >> > > >> > Andy > >> > > >> > _______________________________________________ > >> > Rxtx mailing list > >> > Rxtx at qbang.org > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > >> > >> > >> > >> -- > >> Atte: > >> Daniel Dario Morales Salas > >> Ingeniero Civil en Computaci?n e Inform?tica > >> Tel?fono: 02 684 3417 > >> Celular: 09 643 1802 > >> Santiago, Chile > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > WWW: http://www.sharms.org/blog From damorales at gmail.com Wed Feb 3 18:26:38 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 22:26:38 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100204005829.7dc944e1@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: Hello I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva 2010 this is what i get: drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ and i don't have ANY problem with lock files and RXTX in my java software. All i had to do was add this rule to udev: # serial KERNEL=="tty*", GROUP="uucp", MODE="0666" and that was all. Of course my user (metalklesk) is part of uucp group. I did not make /var/lock writable to all users. Greetings ! 2010/2/3 Andy Eskelson > Thanks Steve, > > changing the serial ports back the uucp is not a big problem. I have a > udev rule that can be easily modified already. However I cannot see any > way of dealing with the var/lock problem apart from making it writable to > all. Any thoughts? > > Andy > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > wrote: > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > and is a result of unified udev rules. You can work around this by > > making udev change the group back to uucp until something more > > happens. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > Thanks, > > > > Steve > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > Thanks Daniel, > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > this for other programs for some time. > > > . > > > I don't think that this is the same problem. as far as I can understand > > > things, the lock files are written in var/lock. Previously var/lock and > > > dev/tty-whatever were the same group. Now with var/lock owned by and > with > > > a group of root:root anything other than root cannot create a lock > > > file. Even minicom is broken by this change. > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > Daniel Morales Salas wrote: > > > > > >> Hi > > >> > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > the uucp > > >> group did not work as it used to be in earlier versions of linux > distros, > > >> causing RXTX to not work as non root user. > > >> > > >> The problem appears because the existense of UDEV, now you MUST add a > RULE > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > the > > >> Serial Port. > > >> > > >> To solve the problem, without needing to recompile RXTX, you must add > a rule > > >> to grant permissions (0666) to the group for the device or port (tty*, > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > i > > >> come back home i will give it to you (i am at work now). > > >> > > >> Greetings ! > > >> > > >> 2010/2/3 > > >> > > >> > Hello RXTX group, > > >> > > > >> > I have just joined this group, and this is my first posting. > > >> > I wanted to pass on some information regarding rxtx, so apologies > if > > >> > this has been brought up before. I have searched back through the > > >> > archives but nothing specific came up. > > >> > > > >> > I am not a Java programmer, and I only came across rxtx a few days > ago. > > >> > > > >> > I use a piece of test equipment called a miniVNA > > >> > http://www.miniradiosolutions.com/ > > >> > > > >> > This is a serial USB controlled instrument, and it has control > software > > >> > available for MS windows, and a very old and now non-working Linux > > >> > application. > > >> > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > control the > > >> > miniVNA, obviously this application makes use of rxtx. > > >> > > > >> > The program worked fine on Windows, so I set about installing it > onto > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > running > > >> > fairly easily, sorting out the file locking by adding the uucp group > to > > >> > the users account as suggested (I used the 2.2pre binary files) I > then > > >> > passed the install instructions onto another miniVNA user, who also > uses > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > >> > also having file lock problems, but the uucp fix did not work. > Digging > > >> > into his system I found that there have been some changes in SUSE > 11.2. > > >> > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > >> > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > >> > checked, so: > > >> > > > >> > SUSE 11.1, var/lock is root:uucp > > >> > SUSE 11.2 var/lock is root:root > > >> > > > >> > A search on Google brought up several comments regarding this, and > also > > >> > a bugzilla entry. > > >> > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > >> > > > >> > However from reading the various posts, some of which are in the > bugzilla > > >> > entry, it appears that many distros may be, or have changed to this > > >> > configuration, and this will undoubtedly break several things, rxtx > > >> > included. > > >> > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > with the > > >> > no lock file option during configure, and that solved his problem. > > >> > > > >> > As this issue will probably take some time to get resolved across > all the > > >> > various Linux distros, it might be worth considering changing the > default > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > >> > versions of the lib in the binary archive. > > >> > > > >> > Thanks for your indulgence > > >> > > > >> > Andy > > >> > > > >> > _______________________________________________ > > >> > Rxtx mailing list > > >> > Rxtx at qbang.org > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > >> > > > >> > > >> > > >> > > >> -- > > >> Atte: > > >> Daniel Dario Morales Salas > > >> Ingeniero Civil en Computaci?n e Inform?tica > > >> Tel?fono: 02 684 3417 > > >> Celular: 09 643 1802 > > >> Santiago, Chile > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at qbang.org > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > -- > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > WWW: http://www.sharms.org/blog > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Thu Feb 4 05:31:46 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 12:31:46 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: <20100204123146.6cffeb67@workstation.site> Thank's for the confirmation. Something odd is going on somewhere in SUSE 11.2. I'll have to build up a local SUSE11.2 system to see if I can nail down exactly what is going on. Something is blocking the lockfiles in var/lock. The net is nice, but it's a bit difficult trying to work out what is going on what the machine in question is in Germany and I'm in the UK :-) Andy On Wed, 3 Feb 2010 22:26:38 -0300 Daniel Morales Salas wrote: > Hello > > I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva > 2010 this is what i get: > > drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ > > and i don't have ANY problem with lock files and RXTX in my java software. > All i had to do was add this rule to udev: > > # serial > KERNEL=="tty*", GROUP="uucp", MODE="0666" > > and that was all. Of course my user (metalklesk) is part of uucp group. > I did not make /var/lock writable to all users. > > Greetings ! > > 2010/2/3 Andy Eskelson > > > Thanks Steve, > > > > changing the serial ports back the uucp is not a big problem. I have a > > udev rule that can be easily modified already. However I cannot see any > > way of dealing with the var/lock problem apart from making it writable to > > all. Any thoughts? > > > > Andy > > > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > > wrote: > > > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > > and is a result of unified udev rules. You can work around this by > > > making udev change the group back to uucp until something more > > > happens. > > > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > > > Thanks, > > > > > > Steve > > > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > > Thanks Daniel, > > > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > > this for other programs for some time. > > > > . > > > > I don't think that this is the same problem. as far as I can understand > > > > things, the lock files are written in var/lock. Previously var/lock and > > > > dev/tty-whatever were the same group. Now with var/lock owned by and > > with > > > > a group of root:root anything other than root cannot create a lock > > > > file. Even minicom is broken by this change. > > > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > > Daniel Morales Salas wrote: > > > > > > > >> Hi > > > >> > > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > > the uucp > > > >> group did not work as it used to be in earlier versions of linux > > distros, > > > >> causing RXTX to not work as non root user. > > > >> > > > >> The problem appears because the existense of UDEV, now you MUST add a > > RULE > > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > > the > > > >> Serial Port. > > > >> > > > >> To solve the problem, without needing to recompile RXTX, you must add > > a rule > > > >> to grant permissions (0666) to the group for the device or port (tty*, > > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > > i > > > >> come back home i will give it to you (i am at work now). > > > >> > > > >> Greetings ! > > > >> > > > >> 2010/2/3 > > > >> > > > >> > Hello RXTX group, > > > >> > > > > >> > I have just joined this group, and this is my first posting. > > > >> > I wanted to pass on some information regarding rxtx, so apologies > > if > > > >> > this has been brought up before. I have searched back through the > > > >> > archives but nothing specific came up. > > > >> > > > > >> > I am not a Java programmer, and I only came across rxtx a few days > > ago. > > > >> > > > > >> > I use a piece of test equipment called a miniVNA > > > >> > http://www.miniradiosolutions.com/ > > > >> > > > > >> > This is a serial USB controlled instrument, and it has control > > software > > > >> > available for MS windows, and a very old and now non-working Linux > > > >> > application. > > > >> > > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > > control the > > > >> > miniVNA, obviously this application makes use of rxtx. > > > >> > > > > >> > The program worked fine on Windows, so I set about installing it > > onto > > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > > running > > > >> > fairly easily, sorting out the file locking by adding the uucp group > > to > > > >> > the users account as suggested (I used the 2.2pre binary files) I > > then > > > >> > passed the install instructions onto another miniVNA user, who also > > uses > > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > > >> > also having file lock problems, but the uucp fix did not work. > > Digging > > > >> > into his system I found that there have been some changes in SUSE > > 11.2. > > > >> > > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > > >> > > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > > >> > checked, so: > > > >> > > > > >> > SUSE 11.1, var/lock is root:uucp > > > >> > SUSE 11.2 var/lock is root:root > > > >> > > > > >> > A search on Google brought up several comments regarding this, and > > also > > > >> > a bugzilla entry. > > > >> > > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > >> > > > > >> > However from reading the various posts, some of which are in the > > bugzilla > > > >> > entry, it appears that many distros may be, or have changed to this > > > >> > configuration, and this will undoubtedly break several things, rxtx > > > >> > included. > > > >> > > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > > with the > > > >> > no lock file option during configure, and that solved his problem. > > > >> > > > > >> > As this issue will probably take some time to get resolved across > > all the > > > >> > various Linux distros, it might be worth considering changing the > > default > > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > > >> > versions of the lib in the binary archive. > > > >> > > > > >> > Thanks for your indulgence > > > >> > > > > >> > Andy > > > >> > > > > >> > _______________________________________________ > > > >> > Rxtx mailing list > > > >> > Rxtx at qbang.org > > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > > >> > > > > >> > > > >> > > > >> > > > >> -- > > > >> Atte: > > > >> Daniel Dario Morales Salas > > > >> Ingeniero Civil en Computaci?n e Inform?tica > > > >> Tel?fono: 02 684 3417 > > > >> Celular: 09 643 1802 > > > >> Santiago, Chile > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at qbang.org > > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > > > -- > > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > > > WWW: http://www.sharms.org/blog > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From Bob_Jacobsen at lbl.gov Thu Feb 4 09:26:49 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Thu, 4 Feb 2010 08:26:49 -0800 Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 Message-ID: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're using RXTX-2.2pre2, although it emits the known message about "Version mismatch". WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 After the usual messing around, we've got it working on 11 Windows versions, multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ have things working rarely say so, so I don't know whether anybody has gotten it to work on 10.4 or not. The problem encountered is this: dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib dyld: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib followed by the JVM crashing hard. I've got those dump files if that would help. Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If so, is there a patch I can get and build? Thanks Bob -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From tjarvi at qbang.org Thu Feb 4 14:22:21 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 4 Feb 2010 14:22:21 -0700 (MST) Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 In-Reply-To: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> References: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> Message-ID: On Thu, 4 Feb 2010, Bob Jacobsen wrote: > We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're > using RXTX-2.2pre2, although it emits the known message about "Version > mismatch". > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > > After the usual messing around, we've got it working on 11 Windows versions, > multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with > a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ > have things working rarely say so, so I don't know whether anybody has gotten > it to work on 10.4 or not. > > The problem encountered is this: > > dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > dyld: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > followed by the JVM crashing hard. I've got those dump files if that would > help. > > Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If > so, is there a patch I can get and build? > Hi Bob, I talked to a coworker about the problem you ran into. It appears that it is possible to target 'older' Mac systems through makefile configuration changes. "Configuring a Makefile-Based Project If you have a makefile-based project, you can also take advantage of SDK-based development, by adding the appropriate options to your compile and link commands. Using SDKs in makefile-based projects requires GCC 4.0 or later. To choose an SDK, you use the -isysroot option with the compiler and the -syslibroot option with the linker. Both options require that you specify the full path to the desired SDK directory. To set the Deployment OS version in a makefile, use a makefile variable of the form: ENVP= MACOSX_DEPLOYMENT_TARGET=10.4. To use this variable in your makefile, include it in front of your compile and link commands." http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html Or build on the oldest system you want to support. -- Trent Jarvi tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Thu Feb 4 14:56:19 2010 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Thu, 4 Feb 2010 14:56:19 -0700 Subject: [Rxtx] RXTX on 64 Bit Redhat In-Reply-To: References: <4ec9eab61001281448g3dd84910r867619948a4e0d7a@mail.gmail.com> Message-ID: Trent -- Finally fixed all my build related issues. I ran into another issue. On one of my machines my JDK is returning multiple folders for the "java.ext.dirs" (java.ext.dirs -> /opt/jdk1.6.0_17/jre/lib/ext:/usr/java/packages/lib/ext) system property. As a result my JVM wasn't able to detect the gnu.io.rxtx.properties. I am attaching a patch for RXTXCommDriver.java file to check for multiple locations. Also i have to assign permission 660 to all my dev ports to be located by RXTX. Pawan ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 5:12 PM To: Trent Jarvi Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Here is the error i get when i build the src from release-2-1-7 -bash-3.2$ make ( \ \ cd i686-pc-linux-gnu; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/ jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I/opt/jav a1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec - c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialImp.lo;\ if [ "Serial" = "Serial" ]; then \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I /opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_tim espec -c /home/jb_stg/rxtx/rxtx-devel/./src/fuserImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ else \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo; \ fi; \ ) gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/inclu de -I/opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need _timespec -c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -fPIC -DPIC -o /hom e/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/.libs/SerialImp.o /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:25:29: error: gnu_io_RXTXPort.h: No such file or directory In file included from /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:113: /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:91: error: expected specifier-qua lifier-list before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'jobject' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:408: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:409: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:410: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:411: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:415: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:416: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:417: error: expected '=', ',', '; ', 'asm' or '__attribute__' before 'is_interrupted' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:418: error: expected declaration specifiers or '...' before 'jint' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:424: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:441: error: expected ')' before ' *' token ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 4:57 PM To: Santosh Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Santosh -- Thank you. That fixed the issue. All -- What CVS branch or release should i use to get the latest RXTX src code. Pawan ________________________________ From: Santosh [mailto:santosh.ry at gmail.com] Sent: Thursday, January 28, 2010 3:49 PM To: Kharbanda, Pawan Cc: Trent Jarvi; rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat error "./configure: /bin/sh^M: bad interpreter: No such file or directory". I think you need to run dos2unix on script files before compiling. Thanks, Santosh On Thu, Jan 28, 2010 at 5:33 PM, Kharbanda, Pawan > wrote: Trent -- We are upgrading our exisiting OS and JDK on a project that rely heavily on RXTX api's. We are now using JDK1.6 32 bit (build 1.6.0_17-b04) and RedHat 5 on a 64 bit machine. Linux tocrhstg02.dot.state.co.us 2.6.18-164.6.1.el5 #1 SMP Tue Oct 27 11:30:06 EDT 2009 i686 i686 i386 GNU/Linux Red Hat Enterprise Linux Server release 5.4 (Tikanga) I tried to run version 2.1.7 r2 on it but not able to see any of my Digi ports I was able to access only /dev/ttyS0 (physical ports). Not sure if the problem is with the Digi driver or RXTX. I tried to open a Digi port with minicom and it worked fine. I also tried to get latest from CVS (rxtx-devel) and when I do "configure" I see this error "./configure: /bin/sh^M: bad interpreter: No such file or directory". Can someone please help me with this? Thanks for the help. Pawan _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch.txt URL: From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 01:02:21 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 13:32:21 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> My serial port driver(apparently) does not support receive timeout.I registered an event listener for DATA_AVAILABLE. However, the control never seems to come out of the 'while' loop.Shouldn't the InputStream.read return a '-1' immediately if no data is available (this seems to be the default operation)? This was tried on a x86 Linux desktop using rxtx-2.1-7 I've added the snippet for clarity: /******************************************************************************************************************************************************************************/ mySerialPort.enableReceiveThreshold(2000);//Trying to set a time limit for read calls System.out.println(mySerialPort.isReceiveTimeoutEnabled()); // I get FALSE, so its not supported on hardware. mySerialPort.addEventListener(this); mySerialPort.notifyOnDataAvailable(true);//register a event with //my SerialEvent listener implementation: public void serialEvent(SerialPortEvent arg0) { int newData=0; switch(arg0.getEventType()){ case SerialPortEvent.DATA_AVAILABLE: while (newData != -1) { try { newData = is.read();//This should eventually return a -1 if no data is available within a timeout.PROBLEM!! System.out.println("Got a byte from port:"+newData); if (newData == -1) { break; } } catch (IOException ex) { System.err.println(ex); return; } } break; } return; } /******************************************************************************************************************************************************************************/ Thanks and regards, Ravi From michael.erskine at ketech.com Wed Feb 3 02:26:50 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 09:26:50 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From michael.erskine at ketech.com Wed Feb 3 05:03:30 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 12:03:30 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > Michael Erskine > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > > Your event handler should handle the event and return immediately so that its > controlling thread can handle other events. I recommend a single read in the > following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) > reads all available bytes up to the size of the buffer returning the number of > bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } After posting this I considered the glaring possibility of the rawbuf read buffer being too small to receive all the available bytes and perhaps skipping data: after all, I'm guessing that is why we see so many posts asking for help with blocking implementations of read event handlers looping on "while(bytes are available)". I've spent this morning writing an extensive multi-threaded unit test suite that includes tests with a tiny buffer compared to the amount of data available and found that no data was being skipped. I now want to know why! The SerialPortEvent.DATA_AVAILABLE event must be being fired again if there is more data available on the input stream. If that is the case then it should be heavily documented with good examples in the wiki to avoid the types of developer anguish we see so regularly. BTW: I'm not at liberty to post the JUnit tests as they use my company's unit test suite framework. Regards, Michael Erskine. From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 06:18:04 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 18:48:04 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Hello Michael, I tried out your suggestion but the problem is that the read(rawbuf) blocks until the entire length of the rawbuf array has been read (blocking). I cannot decide on a reasonable size of the array because it varies from 2 bytes to as much as 50 byes (i'm communicating with a modem,each response is of a different length), which is why i wanted to use non blocking calls. But on a side note, read(byte[]) in turn calls the read() in a loop.In the native C function, the read is supposed to return a -1 upon timeout.But my driver does not support timeout.The default timeout value is zero and the linux select call upon zero time out causes an infinite wait.What am i missing...... Thanks and regards, Ravi Date: Wed, 3 Feb 2010 09:26:50 +0000 From: Michael Erskine To: "rxtx at qbang.org" Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: Content-Type: text/plain; charset="us-ascii" > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From m.kirkland at comcast.net Wed Feb 3 06:46:03 2010 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 3 Feb 2010 05:46:03 -0800 Subject: [Rxtx] One port blocking another port In-Reply-To: References: Message-ID: <68768633814F4D7D86761D34F0764FE0@bengal.net> It turns out this is caused by having the RTS/CTS flow control turned on and me not providing a true on the RTS pin. Somehow it seems the port timing out on a read allows the write to proceed. This is not an issue for my application but I wonder if the write should not proceed until the RTS pin is true even if a read times out. mk -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Monday, January 25, 2010 7:48 PM To: Mike Kirkland Cc: rxtx at qbang.org Subject: Re: [Rxtx] One port blocking another port On Mon, 25 Jan 2010, Mike Kirkland wrote: > > Hi All, > > ? > > I have a program that reads from one com port and writes to another com > port. It also does the same thing in reverse (reads from the second com port > and writes to the first one. It basically ties two com ports together. > > ? > > One port is very chatty and has a consent stream of data. The other port has > very little data. > > ? > > Both ports use a 5000 ms (5 second) time out. > > ? > > The issue I am having is that is appears that the first port?s write to the > second port is blocked while the second port is waiting for input. The first > port?s write proceeds only after the second port has timed out. > > ? > > I suppose I could have something twisted around in my code but I was > wondering if this is a know issue? > Hi Kirk, I've not seen a report like this. Perhaps some simple reproduction code will reveal a problem on your end or help us identify a problem in rxtx. I think there are several users doing multiport communication. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Wed Feb 3 07:03:58 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:03:58 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Message-ID: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> 2010/2/3 Ravishankar N > Hello Michael, > [..] > But on a side note, read(byte[]) in turn calls the read() in a loop.In the > native C function, the read is supposed to return a -1 upon timeout.But my > driver > does not support timeout.The default timeout value is zero and the linux > select call upon zero time out causes an infinite wait.What am i > missing...... > > When I have tested RXTX between platforms, I have observed "hangup" inside JNI driver when no data in Linux, is normal thing. Solution was setting the timeout for RXTX when no data from JNI driver. Something like that: commPort.enableReceiveTimeout(10); And it works perfect.... The only difference is that I am NOT using events - I am using continous read in separate thread and if data is available, is parsed and transferred to application using exception. Regards Mariusz > Thanks and regards, > Ravi > > Date: Wed, 3 Feb 2010 09:26:50 +0000 > From: Michael Erskine > To: "rxtx at qbang.org" > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > Message-ID: > > > Content-Type: text/plain; charset="us-ascii" > > > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of > > Ravishankar N > > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > > > My serial port driver(apparently) does not support receive timeout.I > > registered an event listener for DATA_AVAILABLE. However, the control > never > > seems to come out of the 'while' loop.Shouldn't the > > InputStream.read return a '-1' immediately if no data is available (this > seems > > to be the default operation)? > > Your event handler should handle the event and return immediately so that > its controlling thread can handle other events. I recommend a single read in > the following manner: rawbuf is a byte[] of "reasonable" size and the > read(byte[]) reads all available bytes up to the size of the buffer > returning the number of bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } > > This style of reading has worked for me with RXTX on Linux and Windows XP > for a good few years now in railway industry communications systems. Any > timeouts (largely unnecessary in my applications) can be handled elsewhere, > usually at a higher layer. > > Regards, > Michael Erskine. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Feb 3 07:22:55 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 3 Feb 2010 09:22:55 -0500 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: I'm guessing that this is driver specific. I recently had to support a select()/poll() infrastructure for a linux serial DD, its certainly non trivial to support async IO, so I suspect the problem in this case has to do with missing poll infrastructure in the device driver. This also has to coupled with special open flags for the device (which is within the rxtx code) The key routines within a 2.6 kernel linux device driver are shown below (if you have access to it for your particular device) are indicated below (here is a snippet from my device driver c code that supports polling/select). User space code to test this shown below also, note that the device needs to be opened with the O_NONBLOCK option to support the select/poll api // device driver code ..... /* * File operations supported by this driver. */ static struct file_operations iop_fops = { .owner = THIS_MODULE, .check_flags= iop_check_flags, .ioctl = iop_ioctl, .open = iop_open, .poll = iop_poll, // SUPPORT FOR SELECT/POLL infrastructure .read = iop_read, .release = iop_release, .write = iop_write, }; /** * Select/poll/epoll infrastructure. * * @param file * @param wait * * @return */ static unsigned int iop_poll(struct file *filp, poll_table *wait) { struct iop_device *devp = (struct iop_device *)filp->private_data; // the poll_table wait arg is an opaque pointer poll_wait(filp, &devp->readq, wait); // return from poll indicating whether we have read/write data unsigned int mask = 0; if (kfifo_len(devp->rx_fifo)) { mask |= (POLLIN | POLLRDNORM); } // @JC We don't do select on write yet // if (kfifo_len(devp->tx_fifo)) { // mask |= (POLLOUT | POLLWRNORM); // } // Only print out while debugging // if (mask != 0) { // printk (KERN_INFO "%s: [%04x]\n", __FUNCTION__, mask); // } return mask; } /** * device driver blocking and non blocking read function. This * function reads the requested number of bytes from the read * kfifo blocking as required. * * @param filp * @param buf * @param count * @param f_pos * * @return */ static ssize_t iop_read(struct file *filp, char __user *buf, size_t count, loff_t * ppos) { // access appropriate device struct struct iop_device *devp = (struct iop_device *) filp->private_data; ssize_t retval; // support non blocking mode (default) by checking if the kfifo is empty first if ((kfifo_len(devp->rx_fifo)==0) && (filp->f_flags & O_NONBLOCK)) { return -EAGAIN; } // wait for rx_fifo to receive data via receive interrupts retval = wait_event_interruptible(devp->readq, kfifo_len(devp->rx_fifo) != 0); // check for some error condition if (retval) { printk (KERN_ERR "%s: wait_event_interruptible returned[%d]\n", __FUNCTION__, retval); return retval; } // copy max requested bytes from rx_fifo to device buffer // this may still leave bytes in the kfifo for a subsequent read // if we are reading in a loop retval = kfifo_get(devp->rx_fifo, devp->rxbuf, count); // printk (KERN_INFO "%s: [%d] byte(s)\n", __FUNCTION__, retval); if (copy_to_user(buf, devp->rxbuf, retval)) { printk (KERN_ERR "%s: problem copying rx_fifo data to user buffer\n", __FUNCTION__); return -EFAULT; } return retval; } // a selection of my user space code reading via select()/poll()..... // user space open code iop_fd = ::open( deviceName.data(), O_RDWR | O_NONBLOCK); while ((bytes_to_expect - bytes_read) > 0) { // must reinitialize these between select calls fd_set readfds; FD_ZERO( &readfds ); FD_SET( iop_fd, &readfds ); // 1s sec read polling timeout struct timeval timeout; timeout.tv_sec = 1; timeout.tv_usec = 0; int rc = select( FD_SETSIZE, &readfds, NULL, NULL, &timeout ); // read from file when descriptor // indicates data available without blocking if ((rc > 0) && FD_ISSET(iop_fd, &readfds)) { // read into the appropriate offset within the rx_buf int temp = read(iop_fd, rx_buf + bytes_read, bytes_to_expect - bytes_read); if (!temp) { printf("EOF detected with %d bytes expected\n", bytes_to_expect - bytes_read); } else { bytes_read += temp; } } else if (rc < 0){ printf("%s: select on [%s], bytes_read[%d], errno=%d\n", __FUNCTION__, thread_args->device, bytes_read, errno); } else { printf("%s: select on [%s], bytes_read[%d], timeout\n", __FUNCTION__, thread_args->device, bytes_read); } } On Wed, Feb 3, 2010 at 9:03 AM, Mariusz Dec wrote: > > > 2010/2/3 Ravishankar N > >> Hello Michael, >> [..] >> >> But on a side note, read(byte[]) in turn calls the read() in a loop.In the >> native C function, the read is supposed to return a -1 upon timeout.But my >> driver >> does not support timeout.The default timeout value is zero and the linux >> select call upon zero time out causes an infinite wait.What am i >> missing...... >> >> > When I have tested RXTX between platforms, I have observed "hangup" inside > JNI driver when no data in Linux, is normal thing. > > Solution was setting the timeout for RXTX when no data from JNI driver. > > Something like that: > > commPort.enableReceiveTimeout(10); > > And it works perfect.... > > The only difference is that I am NOT using events - I am using continous > read in separate thread and if data is available, is parsed and transferred > to application using exception. > > Regards > Mariusz > > > >> Thanks and regards, >> Ravi >> >> Date: Wed, 3 Feb 2010 09:26:50 +0000 >> From: Michael Erskine >> To: "rxtx at qbang.org" >> Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? >> Message-ID: >> >> >> Content-Type: text/plain; charset="us-ascii" >> >> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >> Of >> > Ravishankar N >> > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? >> > >> > My serial port driver(apparently) does not support receive timeout.I >> > registered an event listener for DATA_AVAILABLE. However, the control >> never >> > seems to come out of the 'while' loop.Shouldn't the >> > InputStream.read return a '-1' immediately if no data is available (this >> seems >> > to be the default operation)? >> >> Your event handler should handle the event and return immediately so that >> its controlling thread can handle other events. I recommend a single read in >> the following manner: rawbuf is a byte[] of "reasonable" size and the >> read(byte[]) reads all available bytes up to the size of the buffer >> returning the number of bytes actually read... >> >> case SerialPortEvent.DATA_AVAILABLE: >> try { >> int i = is.read(rawbuf); >> if (i == -1) { >> << process EOF condition - should never happen >> >> return; >> } >> << process bytes (rawbuf, i); >> >> return; >> } catch (IOException e) { >> << promptly deal with exception >> >> return; >> } >> >> This style of reading has worked for me with RXTX on Linux and Windows XP >> for a good few years now in railway industry communications systems. Any >> timeouts (largely unnecessary in my applications) can be handled elsewhere, >> usually at a higher layer. >> >> Regards, >> Michael Erskine. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Feb 3 07:33:27 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:33:27 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: <73a89f361002030633j682610afia48dc7accd8e049b@mail.gmail.com> 2010/2/3 John Coffey > I'm guessing that this is driver specific. I recently had to support a > select()/poll() infrastructure for a linux serial DD, its certainly non > trivial to support async IO, so I suspect the problem in this case has to do > with missing poll infrastructure in the device driver. This also has to > coupled with special open flags for the device (which is within the rxtx > code) > > Yes, you are right, it may be driver specific, but in my case I haven't changed blocking JNI driver. I have added ONLY one call to RXTX method mentioned in my previous post and blocking (as seen as from Java app) gone out... Maybe this is not elegant, but works without problem in my app. I am using only FTDI chips and their drivers from couple of years and maybe this is the kind of the way to have no many problems with serial as well? Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From andyrxtx at g0poy.co.uk Wed Feb 3 11:09:04 2010 From: andyrxtx at g0poy.co.uk (andyrxtx at g0poy.co.uk) Date: Wed, 3 Feb 2010 18:09:04 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes Message-ID: <20100203180904.164f24dd@workstation.site> ?Hello RXTX group, I have just joined this group, and this is my first posting. I wanted to pass on some information regarding rxtx, so apologies if this has been brought up before. I have searched back through the archives but nothing specific came up. I am not a Java programmer, and I only came across rxtx a few days ago. I use a piece of test equipment called a miniVNA http://www.miniradiosolutions.com/ This is a serial USB controlled instrument, and it has control software available for MS windows, and a very old and now non-working Linux application. A few days ago Dietmar, DL2SBA released a Java application to control the miniVNA, obviously this application makes use of rxtx. The program worked fine on Windows, so I set about installing it onto Linux. I use SUSE11.1 After a few false starts, I got the system running fairly easily, sorting out the file locking by adding the uucp group to the users account as suggested (I used the 2.2pre binary files) I then passed the install instructions onto another miniVNA user, who also uses SUSE, but he ran into problems. To cut a long story short, he was also having file lock problems, but the uucp fix did not work. Digging into his system I found that there have been some changes in SUSE 11.2. tty ports are now assigned to the dialout group rather than uucp. A hint in the rxtx INSTALL file, suggested that var/lock needs to be checked, so: SUSE 11.1, var/lock is root:uucp SUSE 11.2 var/lock is root:root A search on Google brought up several comments regarding this, and also a bugzilla entry. https://bugzilla.novell.com/show_bug.cgi?id=552095 However from reading the various posts, some of which are in the bugzilla entry, it appears that many distros may be, or have changed to this configuration, and this will undoubtedly break several things, rxtx included. I solved my fellow SUSE users problem by compiling the rxtx libs with the no lock file option during configure, and that solved his problem. As this issue will probably take some time to get resolved across all the various Linux distros, it might be worth considering changing the default on the Linux build of rxtx not to use lockfiles, or provide the two versions of the lib in the binary archive. Thanks for your indulgence Andy From damorales at gmail.com Wed Feb 3 11:33:23 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 15:33:23 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203180904.164f24dd@workstation.site> References: <20100203180904.164f24dd@workstation.site> Message-ID: Hi I had the same problem in Mandriva 2010 and yes, adding the user to the uucp group did not work as it used to be in earlier versions of linux distros, causing RXTX to not work as non root user. The problem appears because the existense of UDEV, now you MUST add a RULE so the group (uucp or whatever) have access (Read, Write, Execute) to the Serial Port. To solve the problem, without needing to recompile RXTX, you must add a rule to grant permissions (0666) to the group for the device or port (tty*, ttyUSB*, etc). I do not remember now what is the line i added but when i come back home i will give it to you (i am at work now). Greetings ! 2010/2/3 > Hello RXTX group, > > I have just joined this group, and this is my first posting. > I wanted to pass on some information regarding rxtx, so apologies if > this has been brought up before. I have searched back through the > archives but nothing specific came up. > > I am not a Java programmer, and I only came across rxtx a few days ago. > > I use a piece of test equipment called a miniVNA > http://www.miniradiosolutions.com/ > > This is a serial USB controlled instrument, and it has control software > available for MS windows, and a very old and now non-working Linux > application. > > A few days ago Dietmar, DL2SBA released a Java application to control the > miniVNA, obviously this application makes use of rxtx. > > The program worked fine on Windows, so I set about installing it onto > Linux. I use SUSE11.1 After a few false starts, I got the system running > fairly easily, sorting out the file locking by adding the uucp group to > the users account as suggested (I used the 2.2pre binary files) I then > passed the install instructions onto another miniVNA user, who also uses > SUSE, but he ran into problems. To cut a long story short, he was > also having file lock problems, but the uucp fix did not work. Digging > into his system I found that there have been some changes in SUSE 11.2. > > tty ports are now assigned to the dialout group rather than uucp. > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > checked, so: > > SUSE 11.1, var/lock is root:uucp > SUSE 11.2 var/lock is root:root > > A search on Google brought up several comments regarding this, and also > a bugzilla entry. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > However from reading the various posts, some of which are in the bugzilla > entry, it appears that many distros may be, or have changed to this > configuration, and this will undoubtedly break several things, rxtx > included. > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > no lock file option during configure, and that solved his problem. > > As this issue will probably take some time to get resolved across all the > various Linux distros, it might be worth considering changing the default > on the Linux build of rxtx not to use lockfiles, or provide the two > versions of the lib in the binary archive. > > Thanks for your indulgence > > Andy > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Wed Feb 3 12:07:02 2010 From: andy at g0poy.com (Andy Eskelson) Date: Wed, 3 Feb 2010 19:07:02 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> Message-ID: <20100203190702.1b0e7015@workstation.site> Thanks Daniel, I am aware of the permissions problem, I have had a udev rules to solve this for other programs for some time. . I don't think that this is the same problem. as far as I can understand things, the lock files are written in var/lock. Previously var/lock and dev/tty-whatever were the same group. Now with var/lock owned by and with a group of root:root anything other than root cannot create a lock file. Even minicom is broken by this change. This change is going to have quite a few knock-on effects I think. Andy On Wed, 3 Feb 2010 15:33:23 -0300 Daniel Morales Salas wrote: > Hi > > I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > group did not work as it used to be in earlier versions of linux distros, > causing RXTX to not work as non root user. > > The problem appears because the existense of UDEV, now you MUST add a RULE > so the group (uucp or whatever) have access (Read, Write, Execute) to the > Serial Port. > > To solve the problem, without needing to recompile RXTX, you must add a rule > to grant permissions (0666) to the group for the device or port (tty*, > ttyUSB*, etc). I do not remember now what is the line i added but when i > come back home i will give it to you (i am at work now). > > Greetings ! > > 2010/2/3 > > > Hello RXTX group, > > > > I have just joined this group, and this is my first posting. > > I wanted to pass on some information regarding rxtx, so apologies if > > this has been brought up before. I have searched back through the > > archives but nothing specific came up. > > > > I am not a Java programmer, and I only came across rxtx a few days ago. > > > > I use a piece of test equipment called a miniVNA > > http://www.miniradiosolutions.com/ > > > > This is a serial USB controlled instrument, and it has control software > > available for MS windows, and a very old and now non-working Linux > > application. > > > > A few days ago Dietmar, DL2SBA released a Java application to control the > > miniVNA, obviously this application makes use of rxtx. > > > > The program worked fine on Windows, so I set about installing it onto > > Linux. I use SUSE11.1 After a few false starts, I got the system running > > fairly easily, sorting out the file locking by adding the uucp group to > > the users account as suggested (I used the 2.2pre binary files) I then > > passed the install instructions onto another miniVNA user, who also uses > > SUSE, but he ran into problems. To cut a long story short, he was > > also having file lock problems, but the uucp fix did not work. Digging > > into his system I found that there have been some changes in SUSE 11.2. > > > > tty ports are now assigned to the dialout group rather than uucp. > > > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > checked, so: > > > > SUSE 11.1, var/lock is root:uucp > > SUSE 11.2 var/lock is root:root > > > > A search on Google brought up several comments regarding this, and also > > a bugzilla entry. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > However from reading the various posts, some of which are in the bugzilla > > entry, it appears that many distros may be, or have changed to this > > configuration, and this will undoubtedly break several things, rxtx > > included. > > > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > > no lock file option during configure, and that solved his problem. > > > > As this issue will probably take some time to get resolved across all the > > various Linux distros, it might be worth considering changing the default > > on the Linux build of rxtx not to use lockfiles, or provide the two > > versions of the lib in the binary archive. > > > > Thanks for your indulgence > > > > Andy > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From thisdyingdream at gmail.com Wed Feb 3 12:32:35 2010 From: thisdyingdream at gmail.com (Steven Harms) Date: Wed, 3 Feb 2010 14:32:35 -0500 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203190702.1b0e7015@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: This is currently a bug in OpenSUSE that affects more than just rxtx, and is a result of unified udev rules. You can work around this by making udev change the group back to uucp until something more happens. https://bugzilla.novell.com/show_bug.cgi?id=552095 Thanks, Steve On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > Thanks Daniel, > > I am aware of the permissions problem, I have had a udev rules to solve > this for other programs for some time. > . > I don't think that this is the same problem. as far as I can understand > things, the lock files are written in var/lock. Previously var/lock and > dev/tty-whatever were the same group. Now with var/lock owned by and with > a group of root:root anything other than root cannot create a lock > file. Even minicom is broken by this change. > > This change is going to have quite a few knock-on effects I think. > > > Andy > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > Daniel Morales Salas wrote: > >> Hi >> >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp >> group did not work as it used to be in earlier versions of linux distros, >> causing RXTX to not work as non root user. >> >> The problem appears because the existense of UDEV, now you MUST add a RULE >> so the group (uucp or whatever) have access (Read, Write, Execute) to the >> Serial Port. >> >> To solve the problem, without needing to recompile RXTX, you must add a rule >> to grant permissions (0666) to the group for the device or port (tty*, >> ttyUSB*, etc). I do not remember now what is the line i added but when i >> come back home i will give it to you (i am at work now). >> >> Greetings ! >> >> 2010/2/3 >> >> > Hello RXTX group, >> > >> > I have just joined this group, and this is my first posting. >> > I wanted to pass on ?some information regarding rxtx, so apologies if >> > this has been brought up before. I have searched back through the >> > archives but nothing specific came up. >> > >> > I am not a Java programmer, and I only came across rxtx a few days ago. >> > >> > I use a piece of test equipment called a miniVNA >> > http://www.miniradiosolutions.com/ >> > >> > This is a serial USB controlled instrument, and it has control software >> > available for MS windows, and a very old and now non-working Linux >> > application. >> > >> > A few days ago Dietmar, DL2SBA released a Java application to control the >> > miniVNA, obviously this application makes use of rxtx. >> > >> > The program worked fine on Windows, so I set about installing it onto >> > Linux. I use SUSE11.1 After a few false starts, I got the system running >> > fairly easily, sorting out the file locking by adding the uucp group to >> > the users account as suggested (I used the 2.2pre binary files) I then >> > passed the install instructions onto another miniVNA user, who also uses >> > SUSE, but he ran into problems. To cut a long story short, he was >> > also having file lock problems, but the uucp fix did not work. Digging >> > into his system I found that there have been some changes in SUSE 11.2. >> > >> > tty ports are now assigned to the dialout group rather than uucp. >> > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be >> > checked, so: >> > >> > SUSE 11.1, var/lock is root:uucp >> > SUSE 11.2 var/lock is root:root >> > >> > A search on Google brought up several comments regarding this, and also >> > a ?bugzilla entry. >> > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 >> > >> > However from reading the various posts, some of which are in the bugzilla >> > entry, it appears that many distros may be, or have changed to this >> > configuration, and this will undoubtedly break several things, rxtx >> > included. >> > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the >> > no lock file option during configure, and that solved his problem. >> > >> > As this issue will probably take some time to get resolved across all the >> > various Linux distros, it might be worth considering changing the default >> > on the Linux build of rxtx not to use lockfiles, or provide the two >> > versions of the lib in the binary archive. >> > >> > Thanks for your indulgence >> > >> > Andy >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> >> >> >> -- >> Atte: >> Daniel Dario Morales Salas >> Ingeniero Civil en Computaci?n e Inform?tica >> Tel?fono: 02 684 3417 >> Celular: 09 643 1802 >> Santiago, Chile > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 WWW: http://www.sharms.org/blog From andy at g0poy.com Wed Feb 3 17:58:29 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 00:58:29 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: <20100204005829.7dc944e1@workstation.site> Thanks Steve, changing the serial ports back the uucp is not a big problem. I have a udev rule that can be easily modified already. However I cannot see any way of dealing with the var/lock problem apart from making it writable to all. Any thoughts? Andy On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms wrote: > This is currently a bug in OpenSUSE that affects more than just rxtx, > and is a result of unified udev rules. You can work around this by > making udev change the group back to uucp until something more > happens. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > Thanks, > > Steve > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > Thanks Daniel, > > > > I am aware of the permissions problem, I have had a udev rules to solve > > this for other programs for some time. > > . > > I don't think that this is the same problem. as far as I can understand > > things, the lock files are written in var/lock. Previously var/lock and > > dev/tty-whatever were the same group. Now with var/lock owned by and with > > a group of root:root anything other than root cannot create a lock > > file. Even minicom is broken by this change. > > > > This change is going to have quite a few knock-on effects I think. > > > > > > Andy > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > Daniel Morales Salas wrote: > > > >> Hi > >> > >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > >> group did not work as it used to be in earlier versions of linux distros, > >> causing RXTX to not work as non root user. > >> > >> The problem appears because the existense of UDEV, now you MUST add a RULE > >> so the group (uucp or whatever) have access (Read, Write, Execute) to the > >> Serial Port. > >> > >> To solve the problem, without needing to recompile RXTX, you must add a rule > >> to grant permissions (0666) to the group for the device or port (tty*, > >> ttyUSB*, etc). I do not remember now what is the line i added but when i > >> come back home i will give it to you (i am at work now). > >> > >> Greetings ! > >> > >> 2010/2/3 > >> > >> > Hello RXTX group, > >> > > >> > I have just joined this group, and this is my first posting. > >> > I wanted to pass on ?some information regarding rxtx, so apologies if > >> > this has been brought up before. I have searched back through the > >> > archives but nothing specific came up. > >> > > >> > I am not a Java programmer, and I only came across rxtx a few days ago. > >> > > >> > I use a piece of test equipment called a miniVNA > >> > http://www.miniradiosolutions.com/ > >> > > >> > This is a serial USB controlled instrument, and it has control software > >> > available for MS windows, and a very old and now non-working Linux > >> > application. > >> > > >> > A few days ago Dietmar, DL2SBA released a Java application to control the > >> > miniVNA, obviously this application makes use of rxtx. > >> > > >> > The program worked fine on Windows, so I set about installing it onto > >> > Linux. I use SUSE11.1 After a few false starts, I got the system running > >> > fairly easily, sorting out the file locking by adding the uucp group to > >> > the users account as suggested (I used the 2.2pre binary files) I then > >> > passed the install instructions onto another miniVNA user, who also uses > >> > SUSE, but he ran into problems. To cut a long story short, he was > >> > also having file lock problems, but the uucp fix did not work. Digging > >> > into his system I found that there have been some changes in SUSE 11.2. > >> > > >> > tty ports are now assigned to the dialout group rather than uucp. > >> > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > >> > checked, so: > >> > > >> > SUSE 11.1, var/lock is root:uucp > >> > SUSE 11.2 var/lock is root:root > >> > > >> > A search on Google brought up several comments regarding this, and also > >> > a ?bugzilla entry. > >> > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > >> > > >> > However from reading the various posts, some of which are in the bugzilla > >> > entry, it appears that many distros may be, or have changed to this > >> > configuration, and this will undoubtedly break several things, rxtx > >> > included. > >> > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the > >> > no lock file option during configure, and that solved his problem. > >> > > >> > As this issue will probably take some time to get resolved across all the > >> > various Linux distros, it might be worth considering changing the default > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > >> > versions of the lib in the binary archive. > >> > > >> > Thanks for your indulgence > >> > > >> > Andy > >> > > >> > _______________________________________________ > >> > Rxtx mailing list > >> > Rxtx at qbang.org > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > >> > >> > >> > >> -- > >> Atte: > >> Daniel Dario Morales Salas > >> Ingeniero Civil en Computaci?n e Inform?tica > >> Tel?fono: 02 684 3417 > >> Celular: 09 643 1802 > >> Santiago, Chile > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > WWW: http://www.sharms.org/blog From damorales at gmail.com Wed Feb 3 18:26:38 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 22:26:38 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100204005829.7dc944e1@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: Hello I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva 2010 this is what i get: drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ and i don't have ANY problem with lock files and RXTX in my java software. All i had to do was add this rule to udev: # serial KERNEL=="tty*", GROUP="uucp", MODE="0666" and that was all. Of course my user (metalklesk) is part of uucp group. I did not make /var/lock writable to all users. Greetings ! 2010/2/3 Andy Eskelson > Thanks Steve, > > changing the serial ports back the uucp is not a big problem. I have a > udev rule that can be easily modified already. However I cannot see any > way of dealing with the var/lock problem apart from making it writable to > all. Any thoughts? > > Andy > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > wrote: > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > and is a result of unified udev rules. You can work around this by > > making udev change the group back to uucp until something more > > happens. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > Thanks, > > > > Steve > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > Thanks Daniel, > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > this for other programs for some time. > > > . > > > I don't think that this is the same problem. as far as I can understand > > > things, the lock files are written in var/lock. Previously var/lock and > > > dev/tty-whatever were the same group. Now with var/lock owned by and > with > > > a group of root:root anything other than root cannot create a lock > > > file. Even minicom is broken by this change. > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > Daniel Morales Salas wrote: > > > > > >> Hi > > >> > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > the uucp > > >> group did not work as it used to be in earlier versions of linux > distros, > > >> causing RXTX to not work as non root user. > > >> > > >> The problem appears because the existense of UDEV, now you MUST add a > RULE > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > the > > >> Serial Port. > > >> > > >> To solve the problem, without needing to recompile RXTX, you must add > a rule > > >> to grant permissions (0666) to the group for the device or port (tty*, > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > i > > >> come back home i will give it to you (i am at work now). > > >> > > >> Greetings ! > > >> > > >> 2010/2/3 > > >> > > >> > Hello RXTX group, > > >> > > > >> > I have just joined this group, and this is my first posting. > > >> > I wanted to pass on some information regarding rxtx, so apologies > if > > >> > this has been brought up before. I have searched back through the > > >> > archives but nothing specific came up. > > >> > > > >> > I am not a Java programmer, and I only came across rxtx a few days > ago. > > >> > > > >> > I use a piece of test equipment called a miniVNA > > >> > http://www.miniradiosolutions.com/ > > >> > > > >> > This is a serial USB controlled instrument, and it has control > software > > >> > available for MS windows, and a very old and now non-working Linux > > >> > application. > > >> > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > control the > > >> > miniVNA, obviously this application makes use of rxtx. > > >> > > > >> > The program worked fine on Windows, so I set about installing it > onto > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > running > > >> > fairly easily, sorting out the file locking by adding the uucp group > to > > >> > the users account as suggested (I used the 2.2pre binary files) I > then > > >> > passed the install instructions onto another miniVNA user, who also > uses > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > >> > also having file lock problems, but the uucp fix did not work. > Digging > > >> > into his system I found that there have been some changes in SUSE > 11.2. > > >> > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > >> > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > >> > checked, so: > > >> > > > >> > SUSE 11.1, var/lock is root:uucp > > >> > SUSE 11.2 var/lock is root:root > > >> > > > >> > A search on Google brought up several comments regarding this, and > also > > >> > a bugzilla entry. > > >> > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > >> > > > >> > However from reading the various posts, some of which are in the > bugzilla > > >> > entry, it appears that many distros may be, or have changed to this > > >> > configuration, and this will undoubtedly break several things, rxtx > > >> > included. > > >> > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > with the > > >> > no lock file option during configure, and that solved his problem. > > >> > > > >> > As this issue will probably take some time to get resolved across > all the > > >> > various Linux distros, it might be worth considering changing the > default > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > >> > versions of the lib in the binary archive. > > >> > > > >> > Thanks for your indulgence > > >> > > > >> > Andy > > >> > > > >> > _______________________________________________ > > >> > Rxtx mailing list > > >> > Rxtx at qbang.org > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > >> > > > >> > > >> > > >> > > >> -- > > >> Atte: > > >> Daniel Dario Morales Salas > > >> Ingeniero Civil en Computaci?n e Inform?tica > > >> Tel?fono: 02 684 3417 > > >> Celular: 09 643 1802 > > >> Santiago, Chile > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at qbang.org > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > -- > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > WWW: http://www.sharms.org/blog > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Thu Feb 4 05:31:46 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 12:31:46 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: <20100204123146.6cffeb67@workstation.site> Thank's for the confirmation. Something odd is going on somewhere in SUSE 11.2. I'll have to build up a local SUSE11.2 system to see if I can nail down exactly what is going on. Something is blocking the lockfiles in var/lock. The net is nice, but it's a bit difficult trying to work out what is going on what the machine in question is in Germany and I'm in the UK :-) Andy On Wed, 3 Feb 2010 22:26:38 -0300 Daniel Morales Salas wrote: > Hello > > I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva > 2010 this is what i get: > > drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ > > and i don't have ANY problem with lock files and RXTX in my java software. > All i had to do was add this rule to udev: > > # serial > KERNEL=="tty*", GROUP="uucp", MODE="0666" > > and that was all. Of course my user (metalklesk) is part of uucp group. > I did not make /var/lock writable to all users. > > Greetings ! > > 2010/2/3 Andy Eskelson > > > Thanks Steve, > > > > changing the serial ports back the uucp is not a big problem. I have a > > udev rule that can be easily modified already. However I cannot see any > > way of dealing with the var/lock problem apart from making it writable to > > all. Any thoughts? > > > > Andy > > > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > > wrote: > > > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > > and is a result of unified udev rules. You can work around this by > > > making udev change the group back to uucp until something more > > > happens. > > > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > > > Thanks, > > > > > > Steve > > > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > > Thanks Daniel, > > > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > > this for other programs for some time. > > > > . > > > > I don't think that this is the same problem. as far as I can understand > > > > things, the lock files are written in var/lock. Previously var/lock and > > > > dev/tty-whatever were the same group. Now with var/lock owned by and > > with > > > > a group of root:root anything other than root cannot create a lock > > > > file. Even minicom is broken by this change. > > > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > > Daniel Morales Salas wrote: > > > > > > > >> Hi > > > >> > > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > > the uucp > > > >> group did not work as it used to be in earlier versions of linux > > distros, > > > >> causing RXTX to not work as non root user. > > > >> > > > >> The problem appears because the existense of UDEV, now you MUST add a > > RULE > > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > > the > > > >> Serial Port. > > > >> > > > >> To solve the problem, without needing to recompile RXTX, you must add > > a rule > > > >> to grant permissions (0666) to the group for the device or port (tty*, > > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > > i > > > >> come back home i will give it to you (i am at work now). > > > >> > > > >> Greetings ! > > > >> > > > >> 2010/2/3 > > > >> > > > >> > Hello RXTX group, > > > >> > > > > >> > I have just joined this group, and this is my first posting. > > > >> > I wanted to pass on some information regarding rxtx, so apologies > > if > > > >> > this has been brought up before. I have searched back through the > > > >> > archives but nothing specific came up. > > > >> > > > > >> > I am not a Java programmer, and I only came across rxtx a few days > > ago. > > > >> > > > > >> > I use a piece of test equipment called a miniVNA > > > >> > http://www.miniradiosolutions.com/ > > > >> > > > > >> > This is a serial USB controlled instrument, and it has control > > software > > > >> > available for MS windows, and a very old and now non-working Linux > > > >> > application. > > > >> > > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > > control the > > > >> > miniVNA, obviously this application makes use of rxtx. > > > >> > > > > >> > The program worked fine on Windows, so I set about installing it > > onto > > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > > running > > > >> > fairly easily, sorting out the file locking by adding the uucp group > > to > > > >> > the users account as suggested (I used the 2.2pre binary files) I > > then > > > >> > passed the install instructions onto another miniVNA user, who also > > uses > > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > > >> > also having file lock problems, but the uucp fix did not work. > > Digging > > > >> > into his system I found that there have been some changes in SUSE > > 11.2. > > > >> > > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > > >> > > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > > >> > checked, so: > > > >> > > > > >> > SUSE 11.1, var/lock is root:uucp > > > >> > SUSE 11.2 var/lock is root:root > > > >> > > > > >> > A search on Google brought up several comments regarding this, and > > also > > > >> > a bugzilla entry. > > > >> > > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > >> > > > > >> > However from reading the various posts, some of which are in the > > bugzilla > > > >> > entry, it appears that many distros may be, or have changed to this > > > >> > configuration, and this will undoubtedly break several things, rxtx > > > >> > included. > > > >> > > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > > with the > > > >> > no lock file option during configure, and that solved his problem. > > > >> > > > > >> > As this issue will probably take some time to get resolved across > > all the > > > >> > various Linux distros, it might be worth considering changing the > > default > > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > > >> > versions of the lib in the binary archive. > > > >> > > > > >> > Thanks for your indulgence > > > >> > > > > >> > Andy > > > >> > > > > >> > _______________________________________________ > > > >> > Rxtx mailing list > > > >> > Rxtx at qbang.org > > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > > >> > > > > >> > > > >> > > > >> > > > >> -- > > > >> Atte: > > > >> Daniel Dario Morales Salas > > > >> Ingeniero Civil en Computaci?n e Inform?tica > > > >> Tel?fono: 02 684 3417 > > > >> Celular: 09 643 1802 > > > >> Santiago, Chile > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at qbang.org > > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > > > -- > > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > > > WWW: http://www.sharms.org/blog > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From Bob_Jacobsen at lbl.gov Thu Feb 4 09:26:49 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Thu, 4 Feb 2010 08:26:49 -0800 Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 Message-ID: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're using RXTX-2.2pre2, although it emits the known message about "Version mismatch". WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 After the usual messing around, we've got it working on 11 Windows versions, multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ have things working rarely say so, so I don't know whether anybody has gotten it to work on 10.4 or not. The problem encountered is this: dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib dyld: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib followed by the JVM crashing hard. I've got those dump files if that would help. Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If so, is there a patch I can get and build? Thanks Bob -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From tjarvi at qbang.org Thu Feb 4 14:22:21 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 4 Feb 2010 14:22:21 -0700 (MST) Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 In-Reply-To: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> References: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> Message-ID: On Thu, 4 Feb 2010, Bob Jacobsen wrote: > We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're > using RXTX-2.2pre2, although it emits the known message about "Version > mismatch". > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > > After the usual messing around, we've got it working on 11 Windows versions, > multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with > a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ > have things working rarely say so, so I don't know whether anybody has gotten > it to work on 10.4 or not. > > The problem encountered is this: > > dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > dyld: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > followed by the JVM crashing hard. I've got those dump files if that would > help. > > Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If > so, is there a patch I can get and build? > Hi Bob, I talked to a coworker about the problem you ran into. It appears that it is possible to target 'older' Mac systems through makefile configuration changes. "Configuring a Makefile-Based Project If you have a makefile-based project, you can also take advantage of SDK-based development, by adding the appropriate options to your compile and link commands. Using SDKs in makefile-based projects requires GCC 4.0 or later. To choose an SDK, you use the -isysroot option with the compiler and the -syslibroot option with the linker. Both options require that you specify the full path to the desired SDK directory. To set the Deployment OS version in a makefile, use a makefile variable of the form: ENVP= MACOSX_DEPLOYMENT_TARGET=10.4. To use this variable in your makefile, include it in front of your compile and link commands." http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html Or build on the oldest system you want to support. -- Trent Jarvi tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Thu Feb 4 14:56:19 2010 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Thu, 4 Feb 2010 14:56:19 -0700 Subject: [Rxtx] RXTX on 64 Bit Redhat In-Reply-To: References: <4ec9eab61001281448g3dd84910r867619948a4e0d7a@mail.gmail.com> Message-ID: Trent -- Finally fixed all my build related issues. I ran into another issue. On one of my machines my JDK is returning multiple folders for the "java.ext.dirs" (java.ext.dirs -> /opt/jdk1.6.0_17/jre/lib/ext:/usr/java/packages/lib/ext) system property. As a result my JVM wasn't able to detect the gnu.io.rxtx.properties. I am attaching a patch for RXTXCommDriver.java file to check for multiple locations. Also i have to assign permission 660 to all my dev ports to be located by RXTX. Pawan ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 5:12 PM To: Trent Jarvi Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Here is the error i get when i build the src from release-2-1-7 -bash-3.2$ make ( \ \ cd i686-pc-linux-gnu; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/ jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I/opt/jav a1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec - c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialImp.lo;\ if [ "Serial" = "Serial" ]; then \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I /opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_tim espec -c /home/jb_stg/rxtx/rxtx-devel/./src/fuserImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ else \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo; \ fi; \ ) gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/inclu de -I/opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need _timespec -c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -fPIC -DPIC -o /hom e/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/.libs/SerialImp.o /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:25:29: error: gnu_io_RXTXPort.h: No such file or directory In file included from /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:113: /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:91: error: expected specifier-qua lifier-list before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'jobject' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:408: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:409: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:410: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:411: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:415: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:416: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:417: error: expected '=', ',', '; ', 'asm' or '__attribute__' before 'is_interrupted' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:418: error: expected declaration specifiers or '...' before 'jint' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:424: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:441: error: expected ')' before ' *' token ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 4:57 PM To: Santosh Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Santosh -- Thank you. That fixed the issue. All -- What CVS branch or release should i use to get the latest RXTX src code. Pawan ________________________________ From: Santosh [mailto:santosh.ry at gmail.com] Sent: Thursday, January 28, 2010 3:49 PM To: Kharbanda, Pawan Cc: Trent Jarvi; rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat error "./configure: /bin/sh^M: bad interpreter: No such file or directory". I think you need to run dos2unix on script files before compiling. Thanks, Santosh On Thu, Jan 28, 2010 at 5:33 PM, Kharbanda, Pawan > wrote: Trent -- We are upgrading our exisiting OS and JDK on a project that rely heavily on RXTX api's. We are now using JDK1.6 32 bit (build 1.6.0_17-b04) and RedHat 5 on a 64 bit machine. Linux tocrhstg02.dot.state.co.us 2.6.18-164.6.1.el5 #1 SMP Tue Oct 27 11:30:06 EDT 2009 i686 i686 i386 GNU/Linux Red Hat Enterprise Linux Server release 5.4 (Tikanga) I tried to run version 2.1.7 r2 on it but not able to see any of my Digi ports I was able to access only /dev/ttyS0 (physical ports). Not sure if the problem is with the Digi driver or RXTX. I tried to open a Digi port with minicom and it worked fine. I also tried to get latest from CVS (rxtx-devel) and when I do "configure" I see this error "./configure: /bin/sh^M: bad interpreter: No such file or directory". Can someone please help me with this? Thanks for the help. Pawan _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch.txt URL: From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 01:02:21 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 13:32:21 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> My serial port driver(apparently) does not support receive timeout.I registered an event listener for DATA_AVAILABLE. However, the control never seems to come out of the 'while' loop.Shouldn't the InputStream.read return a '-1' immediately if no data is available (this seems to be the default operation)? This was tried on a x86 Linux desktop using rxtx-2.1-7 I've added the snippet for clarity: /******************************************************************************************************************************************************************************/ mySerialPort.enableReceiveThreshold(2000);//Trying to set a time limit for read calls System.out.println(mySerialPort.isReceiveTimeoutEnabled()); // I get FALSE, so its not supported on hardware. mySerialPort.addEventListener(this); mySerialPort.notifyOnDataAvailable(true);//register a event with //my SerialEvent listener implementation: public void serialEvent(SerialPortEvent arg0) { int newData=0; switch(arg0.getEventType()){ case SerialPortEvent.DATA_AVAILABLE: while (newData != -1) { try { newData = is.read();//This should eventually return a -1 if no data is available within a timeout.PROBLEM!! System.out.println("Got a byte from port:"+newData); if (newData == -1) { break; } } catch (IOException ex) { System.err.println(ex); return; } } break; } return; } /******************************************************************************************************************************************************************************/ Thanks and regards, Ravi From michael.erskine at ketech.com Wed Feb 3 02:26:50 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 09:26:50 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From michael.erskine at ketech.com Wed Feb 3 05:03:30 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 12:03:30 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > Michael Erskine > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > > Your event handler should handle the event and return immediately so that its > controlling thread can handle other events. I recommend a single read in the > following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) > reads all available bytes up to the size of the buffer returning the number of > bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } After posting this I considered the glaring possibility of the rawbuf read buffer being too small to receive all the available bytes and perhaps skipping data: after all, I'm guessing that is why we see so many posts asking for help with blocking implementations of read event handlers looping on "while(bytes are available)". I've spent this morning writing an extensive multi-threaded unit test suite that includes tests with a tiny buffer compared to the amount of data available and found that no data was being skipped. I now want to know why! The SerialPortEvent.DATA_AVAILABLE event must be being fired again if there is more data available on the input stream. If that is the case then it should be heavily documented with good examples in the wiki to avoid the types of developer anguish we see so regularly. BTW: I'm not at liberty to post the JUnit tests as they use my company's unit test suite framework. Regards, Michael Erskine. From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 06:18:04 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 18:48:04 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Hello Michael, I tried out your suggestion but the problem is that the read(rawbuf) blocks until the entire length of the rawbuf array has been read (blocking). I cannot decide on a reasonable size of the array because it varies from 2 bytes to as much as 50 byes (i'm communicating with a modem,each response is of a different length), which is why i wanted to use non blocking calls. But on a side note, read(byte[]) in turn calls the read() in a loop.In the native C function, the read is supposed to return a -1 upon timeout.But my driver does not support timeout.The default timeout value is zero and the linux select call upon zero time out causes an infinite wait.What am i missing...... Thanks and regards, Ravi Date: Wed, 3 Feb 2010 09:26:50 +0000 From: Michael Erskine To: "rxtx at qbang.org" Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: Content-Type: text/plain; charset="us-ascii" > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From m.kirkland at comcast.net Wed Feb 3 06:46:03 2010 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 3 Feb 2010 05:46:03 -0800 Subject: [Rxtx] One port blocking another port In-Reply-To: References: Message-ID: <68768633814F4D7D86761D34F0764FE0@bengal.net> It turns out this is caused by having the RTS/CTS flow control turned on and me not providing a true on the RTS pin. Somehow it seems the port timing out on a read allows the write to proceed. This is not an issue for my application but I wonder if the write should not proceed until the RTS pin is true even if a read times out. mk -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Monday, January 25, 2010 7:48 PM To: Mike Kirkland Cc: rxtx at qbang.org Subject: Re: [Rxtx] One port blocking another port On Mon, 25 Jan 2010, Mike Kirkland wrote: > > Hi All, > > ? > > I have a program that reads from one com port and writes to another com > port. It also does the same thing in reverse (reads from the second com port > and writes to the first one. It basically ties two com ports together. > > ? > > One port is very chatty and has a consent stream of data. The other port has > very little data. > > ? > > Both ports use a 5000 ms (5 second) time out. > > ? > > The issue I am having is that is appears that the first port?s write to the > second port is blocked while the second port is waiting for input. The first > port?s write proceeds only after the second port has timed out. > > ? > > I suppose I could have something twisted around in my code but I was > wondering if this is a know issue? > Hi Kirk, I've not seen a report like this. Perhaps some simple reproduction code will reveal a problem on your end or help us identify a problem in rxtx. I think there are several users doing multiport communication. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Wed Feb 3 07:03:58 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:03:58 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Message-ID: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> 2010/2/3 Ravishankar N > Hello Michael, > [..] > But on a side note, read(byte[]) in turn calls the read() in a loop.In the > native C function, the read is supposed to return a -1 upon timeout.But my > driver > does not support timeout.The default timeout value is zero and the linux > select call upon zero time out causes an infinite wait.What am i > missing...... > > When I have tested RXTX between platforms, I have observed "hangup" inside JNI driver when no data in Linux, is normal thing. Solution was setting the timeout for RXTX when no data from JNI driver. Something like that: commPort.enableReceiveTimeout(10); And it works perfect.... The only difference is that I am NOT using events - I am using continous read in separate thread and if data is available, is parsed and transferred to application using exception. Regards Mariusz > Thanks and regards, > Ravi > > Date: Wed, 3 Feb 2010 09:26:50 +0000 > From: Michael Erskine > To: "rxtx at qbang.org" > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > Message-ID: > > > Content-Type: text/plain; charset="us-ascii" > > > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of > > Ravishankar N > > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > > > My serial port driver(apparently) does not support receive timeout.I > > registered an event listener for DATA_AVAILABLE. However, the control > never > > seems to come out of the 'while' loop.Shouldn't the > > InputStream.read return a '-1' immediately if no data is available (this > seems > > to be the default operation)? > > Your event handler should handle the event and return immediately so that > its controlling thread can handle other events. I recommend a single read in > the following manner: rawbuf is a byte[] of "reasonable" size and the > read(byte[]) reads all available bytes up to the size of the buffer > returning the number of bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } > > This style of reading has worked for me with RXTX on Linux and Windows XP > for a good few years now in railway industry communications systems. Any > timeouts (largely unnecessary in my applications) can be handled elsewhere, > usually at a higher layer. > > Regards, > Michael Erskine. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Feb 3 07:22:55 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 3 Feb 2010 09:22:55 -0500 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: I'm guessing that this is driver specific. I recently had to support a select()/poll() infrastructure for a linux serial DD, its certainly non trivial to support async IO, so I suspect the problem in this case has to do with missing poll infrastructure in the device driver. This also has to coupled with special open flags for the device (which is within the rxtx code) The key routines within a 2.6 kernel linux device driver are shown below (if you have access to it for your particular device) are indicated below (here is a snippet from my device driver c code that supports polling/select). User space code to test this shown below also, note that the device needs to be opened with the O_NONBLOCK option to support the select/poll api // device driver code ..... /* * File operations supported by this driver. */ static struct file_operations iop_fops = { .owner = THIS_MODULE, .check_flags= iop_check_flags, .ioctl = iop_ioctl, .open = iop_open, .poll = iop_poll, // SUPPORT FOR SELECT/POLL infrastructure .read = iop_read, .release = iop_release, .write = iop_write, }; /** * Select/poll/epoll infrastructure. * * @param file * @param wait * * @return */ static unsigned int iop_poll(struct file *filp, poll_table *wait) { struct iop_device *devp = (struct iop_device *)filp->private_data; // the poll_table wait arg is an opaque pointer poll_wait(filp, &devp->readq, wait); // return from poll indicating whether we have read/write data unsigned int mask = 0; if (kfifo_len(devp->rx_fifo)) { mask |= (POLLIN | POLLRDNORM); } // @JC We don't do select on write yet // if (kfifo_len(devp->tx_fifo)) { // mask |= (POLLOUT | POLLWRNORM); // } // Only print out while debugging // if (mask != 0) { // printk (KERN_INFO "%s: [%04x]\n", __FUNCTION__, mask); // } return mask; } /** * device driver blocking and non blocking read function. This * function reads the requested number of bytes from the read * kfifo blocking as required. * * @param filp * @param buf * @param count * @param f_pos * * @return */ static ssize_t iop_read(struct file *filp, char __user *buf, size_t count, loff_t * ppos) { // access appropriate device struct struct iop_device *devp = (struct iop_device *) filp->private_data; ssize_t retval; // support non blocking mode (default) by checking if the kfifo is empty first if ((kfifo_len(devp->rx_fifo)==0) && (filp->f_flags & O_NONBLOCK)) { return -EAGAIN; } // wait for rx_fifo to receive data via receive interrupts retval = wait_event_interruptible(devp->readq, kfifo_len(devp->rx_fifo) != 0); // check for some error condition if (retval) { printk (KERN_ERR "%s: wait_event_interruptible returned[%d]\n", __FUNCTION__, retval); return retval; } // copy max requested bytes from rx_fifo to device buffer // this may still leave bytes in the kfifo for a subsequent read // if we are reading in a loop retval = kfifo_get(devp->rx_fifo, devp->rxbuf, count); // printk (KERN_INFO "%s: [%d] byte(s)\n", __FUNCTION__, retval); if (copy_to_user(buf, devp->rxbuf, retval)) { printk (KERN_ERR "%s: problem copying rx_fifo data to user buffer\n", __FUNCTION__); return -EFAULT; } return retval; } // a selection of my user space code reading via select()/poll()..... // user space open code iop_fd = ::open( deviceName.data(), O_RDWR | O_NONBLOCK); while ((bytes_to_expect - bytes_read) > 0) { // must reinitialize these between select calls fd_set readfds; FD_ZERO( &readfds ); FD_SET( iop_fd, &readfds ); // 1s sec read polling timeout struct timeval timeout; timeout.tv_sec = 1; timeout.tv_usec = 0; int rc = select( FD_SETSIZE, &readfds, NULL, NULL, &timeout ); // read from file when descriptor // indicates data available without blocking if ((rc > 0) && FD_ISSET(iop_fd, &readfds)) { // read into the appropriate offset within the rx_buf int temp = read(iop_fd, rx_buf + bytes_read, bytes_to_expect - bytes_read); if (!temp) { printf("EOF detected with %d bytes expected\n", bytes_to_expect - bytes_read); } else { bytes_read += temp; } } else if (rc < 0){ printf("%s: select on [%s], bytes_read[%d], errno=%d\n", __FUNCTION__, thread_args->device, bytes_read, errno); } else { printf("%s: select on [%s], bytes_read[%d], timeout\n", __FUNCTION__, thread_args->device, bytes_read); } } On Wed, Feb 3, 2010 at 9:03 AM, Mariusz Dec wrote: > > > 2010/2/3 Ravishankar N > >> Hello Michael, >> [..] >> >> But on a side note, read(byte[]) in turn calls the read() in a loop.In the >> native C function, the read is supposed to return a -1 upon timeout.But my >> driver >> does not support timeout.The default timeout value is zero and the linux >> select call upon zero time out causes an infinite wait.What am i >> missing...... >> >> > When I have tested RXTX between platforms, I have observed "hangup" inside > JNI driver when no data in Linux, is normal thing. > > Solution was setting the timeout for RXTX when no data from JNI driver. > > Something like that: > > commPort.enableReceiveTimeout(10); > > And it works perfect.... > > The only difference is that I am NOT using events - I am using continous > read in separate thread and if data is available, is parsed and transferred > to application using exception. > > Regards > Mariusz > > > >> Thanks and regards, >> Ravi >> >> Date: Wed, 3 Feb 2010 09:26:50 +0000 >> From: Michael Erskine >> To: "rxtx at qbang.org" >> Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? >> Message-ID: >> >> >> Content-Type: text/plain; charset="us-ascii" >> >> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >> Of >> > Ravishankar N >> > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? >> > >> > My serial port driver(apparently) does not support receive timeout.I >> > registered an event listener for DATA_AVAILABLE. However, the control >> never >> > seems to come out of the 'while' loop.Shouldn't the >> > InputStream.read return a '-1' immediately if no data is available (this >> seems >> > to be the default operation)? >> >> Your event handler should handle the event and return immediately so that >> its controlling thread can handle other events. I recommend a single read in >> the following manner: rawbuf is a byte[] of "reasonable" size and the >> read(byte[]) reads all available bytes up to the size of the buffer >> returning the number of bytes actually read... >> >> case SerialPortEvent.DATA_AVAILABLE: >> try { >> int i = is.read(rawbuf); >> if (i == -1) { >> << process EOF condition - should never happen >> >> return; >> } >> << process bytes (rawbuf, i); >> >> return; >> } catch (IOException e) { >> << promptly deal with exception >> >> return; >> } >> >> This style of reading has worked for me with RXTX on Linux and Windows XP >> for a good few years now in railway industry communications systems. Any >> timeouts (largely unnecessary in my applications) can be handled elsewhere, >> usually at a higher layer. >> >> Regards, >> Michael Erskine. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Feb 3 07:33:27 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:33:27 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: <73a89f361002030633j682610afia48dc7accd8e049b@mail.gmail.com> 2010/2/3 John Coffey > I'm guessing that this is driver specific. I recently had to support a > select()/poll() infrastructure for a linux serial DD, its certainly non > trivial to support async IO, so I suspect the problem in this case has to do > with missing poll infrastructure in the device driver. This also has to > coupled with special open flags for the device (which is within the rxtx > code) > > Yes, you are right, it may be driver specific, but in my case I haven't changed blocking JNI driver. I have added ONLY one call to RXTX method mentioned in my previous post and blocking (as seen as from Java app) gone out... Maybe this is not elegant, but works without problem in my app. I am using only FTDI chips and their drivers from couple of years and maybe this is the kind of the way to have no many problems with serial as well? Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From andyrxtx at g0poy.co.uk Wed Feb 3 11:09:04 2010 From: andyrxtx at g0poy.co.uk (andyrxtx at g0poy.co.uk) Date: Wed, 3 Feb 2010 18:09:04 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes Message-ID: <20100203180904.164f24dd@workstation.site> ?Hello RXTX group, I have just joined this group, and this is my first posting. I wanted to pass on some information regarding rxtx, so apologies if this has been brought up before. I have searched back through the archives but nothing specific came up. I am not a Java programmer, and I only came across rxtx a few days ago. I use a piece of test equipment called a miniVNA http://www.miniradiosolutions.com/ This is a serial USB controlled instrument, and it has control software available for MS windows, and a very old and now non-working Linux application. A few days ago Dietmar, DL2SBA released a Java application to control the miniVNA, obviously this application makes use of rxtx. The program worked fine on Windows, so I set about installing it onto Linux. I use SUSE11.1 After a few false starts, I got the system running fairly easily, sorting out the file locking by adding the uucp group to the users account as suggested (I used the 2.2pre binary files) I then passed the install instructions onto another miniVNA user, who also uses SUSE, but he ran into problems. To cut a long story short, he was also having file lock problems, but the uucp fix did not work. Digging into his system I found that there have been some changes in SUSE 11.2. tty ports are now assigned to the dialout group rather than uucp. A hint in the rxtx INSTALL file, suggested that var/lock needs to be checked, so: SUSE 11.1, var/lock is root:uucp SUSE 11.2 var/lock is root:root A search on Google brought up several comments regarding this, and also a bugzilla entry. https://bugzilla.novell.com/show_bug.cgi?id=552095 However from reading the various posts, some of which are in the bugzilla entry, it appears that many distros may be, or have changed to this configuration, and this will undoubtedly break several things, rxtx included. I solved my fellow SUSE users problem by compiling the rxtx libs with the no lock file option during configure, and that solved his problem. As this issue will probably take some time to get resolved across all the various Linux distros, it might be worth considering changing the default on the Linux build of rxtx not to use lockfiles, or provide the two versions of the lib in the binary archive. Thanks for your indulgence Andy From damorales at gmail.com Wed Feb 3 11:33:23 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 15:33:23 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203180904.164f24dd@workstation.site> References: <20100203180904.164f24dd@workstation.site> Message-ID: Hi I had the same problem in Mandriva 2010 and yes, adding the user to the uucp group did not work as it used to be in earlier versions of linux distros, causing RXTX to not work as non root user. The problem appears because the existense of UDEV, now you MUST add a RULE so the group (uucp or whatever) have access (Read, Write, Execute) to the Serial Port. To solve the problem, without needing to recompile RXTX, you must add a rule to grant permissions (0666) to the group for the device or port (tty*, ttyUSB*, etc). I do not remember now what is the line i added but when i come back home i will give it to you (i am at work now). Greetings ! 2010/2/3 > Hello RXTX group, > > I have just joined this group, and this is my first posting. > I wanted to pass on some information regarding rxtx, so apologies if > this has been brought up before. I have searched back through the > archives but nothing specific came up. > > I am not a Java programmer, and I only came across rxtx a few days ago. > > I use a piece of test equipment called a miniVNA > http://www.miniradiosolutions.com/ > > This is a serial USB controlled instrument, and it has control software > available for MS windows, and a very old and now non-working Linux > application. > > A few days ago Dietmar, DL2SBA released a Java application to control the > miniVNA, obviously this application makes use of rxtx. > > The program worked fine on Windows, so I set about installing it onto > Linux. I use SUSE11.1 After a few false starts, I got the system running > fairly easily, sorting out the file locking by adding the uucp group to > the users account as suggested (I used the 2.2pre binary files) I then > passed the install instructions onto another miniVNA user, who also uses > SUSE, but he ran into problems. To cut a long story short, he was > also having file lock problems, but the uucp fix did not work. Digging > into his system I found that there have been some changes in SUSE 11.2. > > tty ports are now assigned to the dialout group rather than uucp. > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > checked, so: > > SUSE 11.1, var/lock is root:uucp > SUSE 11.2 var/lock is root:root > > A search on Google brought up several comments regarding this, and also > a bugzilla entry. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > However from reading the various posts, some of which are in the bugzilla > entry, it appears that many distros may be, or have changed to this > configuration, and this will undoubtedly break several things, rxtx > included. > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > no lock file option during configure, and that solved his problem. > > As this issue will probably take some time to get resolved across all the > various Linux distros, it might be worth considering changing the default > on the Linux build of rxtx not to use lockfiles, or provide the two > versions of the lib in the binary archive. > > Thanks for your indulgence > > Andy > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Wed Feb 3 12:07:02 2010 From: andy at g0poy.com (Andy Eskelson) Date: Wed, 3 Feb 2010 19:07:02 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> Message-ID: <20100203190702.1b0e7015@workstation.site> Thanks Daniel, I am aware of the permissions problem, I have had a udev rules to solve this for other programs for some time. . I don't think that this is the same problem. as far as I can understand things, the lock files are written in var/lock. Previously var/lock and dev/tty-whatever were the same group. Now with var/lock owned by and with a group of root:root anything other than root cannot create a lock file. Even minicom is broken by this change. This change is going to have quite a few knock-on effects I think. Andy On Wed, 3 Feb 2010 15:33:23 -0300 Daniel Morales Salas wrote: > Hi > > I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > group did not work as it used to be in earlier versions of linux distros, > causing RXTX to not work as non root user. > > The problem appears because the existense of UDEV, now you MUST add a RULE > so the group (uucp or whatever) have access (Read, Write, Execute) to the > Serial Port. > > To solve the problem, without needing to recompile RXTX, you must add a rule > to grant permissions (0666) to the group for the device or port (tty*, > ttyUSB*, etc). I do not remember now what is the line i added but when i > come back home i will give it to you (i am at work now). > > Greetings ! > > 2010/2/3 > > > Hello RXTX group, > > > > I have just joined this group, and this is my first posting. > > I wanted to pass on some information regarding rxtx, so apologies if > > this has been brought up before. I have searched back through the > > archives but nothing specific came up. > > > > I am not a Java programmer, and I only came across rxtx a few days ago. > > > > I use a piece of test equipment called a miniVNA > > http://www.miniradiosolutions.com/ > > > > This is a serial USB controlled instrument, and it has control software > > available for MS windows, and a very old and now non-working Linux > > application. > > > > A few days ago Dietmar, DL2SBA released a Java application to control the > > miniVNA, obviously this application makes use of rxtx. > > > > The program worked fine on Windows, so I set about installing it onto > > Linux. I use SUSE11.1 After a few false starts, I got the system running > > fairly easily, sorting out the file locking by adding the uucp group to > > the users account as suggested (I used the 2.2pre binary files) I then > > passed the install instructions onto another miniVNA user, who also uses > > SUSE, but he ran into problems. To cut a long story short, he was > > also having file lock problems, but the uucp fix did not work. Digging > > into his system I found that there have been some changes in SUSE 11.2. > > > > tty ports are now assigned to the dialout group rather than uucp. > > > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > checked, so: > > > > SUSE 11.1, var/lock is root:uucp > > SUSE 11.2 var/lock is root:root > > > > A search on Google brought up several comments regarding this, and also > > a bugzilla entry. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > However from reading the various posts, some of which are in the bugzilla > > entry, it appears that many distros may be, or have changed to this > > configuration, and this will undoubtedly break several things, rxtx > > included. > > > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > > no lock file option during configure, and that solved his problem. > > > > As this issue will probably take some time to get resolved across all the > > various Linux distros, it might be worth considering changing the default > > on the Linux build of rxtx not to use lockfiles, or provide the two > > versions of the lib in the binary archive. > > > > Thanks for your indulgence > > > > Andy > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From thisdyingdream at gmail.com Wed Feb 3 12:32:35 2010 From: thisdyingdream at gmail.com (Steven Harms) Date: Wed, 3 Feb 2010 14:32:35 -0500 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203190702.1b0e7015@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: This is currently a bug in OpenSUSE that affects more than just rxtx, and is a result of unified udev rules. You can work around this by making udev change the group back to uucp until something more happens. https://bugzilla.novell.com/show_bug.cgi?id=552095 Thanks, Steve On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > Thanks Daniel, > > I am aware of the permissions problem, I have had a udev rules to solve > this for other programs for some time. > . > I don't think that this is the same problem. as far as I can understand > things, the lock files are written in var/lock. Previously var/lock and > dev/tty-whatever were the same group. Now with var/lock owned by and with > a group of root:root anything other than root cannot create a lock > file. Even minicom is broken by this change. > > This change is going to have quite a few knock-on effects I think. > > > Andy > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > Daniel Morales Salas wrote: > >> Hi >> >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp >> group did not work as it used to be in earlier versions of linux distros, >> causing RXTX to not work as non root user. >> >> The problem appears because the existense of UDEV, now you MUST add a RULE >> so the group (uucp or whatever) have access (Read, Write, Execute) to the >> Serial Port. >> >> To solve the problem, without needing to recompile RXTX, you must add a rule >> to grant permissions (0666) to the group for the device or port (tty*, >> ttyUSB*, etc). I do not remember now what is the line i added but when i >> come back home i will give it to you (i am at work now). >> >> Greetings ! >> >> 2010/2/3 >> >> > Hello RXTX group, >> > >> > I have just joined this group, and this is my first posting. >> > I wanted to pass on ?some information regarding rxtx, so apologies if >> > this has been brought up before. I have searched back through the >> > archives but nothing specific came up. >> > >> > I am not a Java programmer, and I only came across rxtx a few days ago. >> > >> > I use a piece of test equipment called a miniVNA >> > http://www.miniradiosolutions.com/ >> > >> > This is a serial USB controlled instrument, and it has control software >> > available for MS windows, and a very old and now non-working Linux >> > application. >> > >> > A few days ago Dietmar, DL2SBA released a Java application to control the >> > miniVNA, obviously this application makes use of rxtx. >> > >> > The program worked fine on Windows, so I set about installing it onto >> > Linux. I use SUSE11.1 After a few false starts, I got the system running >> > fairly easily, sorting out the file locking by adding the uucp group to >> > the users account as suggested (I used the 2.2pre binary files) I then >> > passed the install instructions onto another miniVNA user, who also uses >> > SUSE, but he ran into problems. To cut a long story short, he was >> > also having file lock problems, but the uucp fix did not work. Digging >> > into his system I found that there have been some changes in SUSE 11.2. >> > >> > tty ports are now assigned to the dialout group rather than uucp. >> > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be >> > checked, so: >> > >> > SUSE 11.1, var/lock is root:uucp >> > SUSE 11.2 var/lock is root:root >> > >> > A search on Google brought up several comments regarding this, and also >> > a ?bugzilla entry. >> > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 >> > >> > However from reading the various posts, some of which are in the bugzilla >> > entry, it appears that many distros may be, or have changed to this >> > configuration, and this will undoubtedly break several things, rxtx >> > included. >> > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the >> > no lock file option during configure, and that solved his problem. >> > >> > As this issue will probably take some time to get resolved across all the >> > various Linux distros, it might be worth considering changing the default >> > on the Linux build of rxtx not to use lockfiles, or provide the two >> > versions of the lib in the binary archive. >> > >> > Thanks for your indulgence >> > >> > Andy >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> >> >> >> -- >> Atte: >> Daniel Dario Morales Salas >> Ingeniero Civil en Computaci?n e Inform?tica >> Tel?fono: 02 684 3417 >> Celular: 09 643 1802 >> Santiago, Chile > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 WWW: http://www.sharms.org/blog From andy at g0poy.com Wed Feb 3 17:58:29 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 00:58:29 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: <20100204005829.7dc944e1@workstation.site> Thanks Steve, changing the serial ports back the uucp is not a big problem. I have a udev rule that can be easily modified already. However I cannot see any way of dealing with the var/lock problem apart from making it writable to all. Any thoughts? Andy On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms wrote: > This is currently a bug in OpenSUSE that affects more than just rxtx, > and is a result of unified udev rules. You can work around this by > making udev change the group back to uucp until something more > happens. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > Thanks, > > Steve > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > Thanks Daniel, > > > > I am aware of the permissions problem, I have had a udev rules to solve > > this for other programs for some time. > > . > > I don't think that this is the same problem. as far as I can understand > > things, the lock files are written in var/lock. Previously var/lock and > > dev/tty-whatever were the same group. Now with var/lock owned by and with > > a group of root:root anything other than root cannot create a lock > > file. Even minicom is broken by this change. > > > > This change is going to have quite a few knock-on effects I think. > > > > > > Andy > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > Daniel Morales Salas wrote: > > > >> Hi > >> > >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > >> group did not work as it used to be in earlier versions of linux distros, > >> causing RXTX to not work as non root user. > >> > >> The problem appears because the existense of UDEV, now you MUST add a RULE > >> so the group (uucp or whatever) have access (Read, Write, Execute) to the > >> Serial Port. > >> > >> To solve the problem, without needing to recompile RXTX, you must add a rule > >> to grant permissions (0666) to the group for the device or port (tty*, > >> ttyUSB*, etc). I do not remember now what is the line i added but when i > >> come back home i will give it to you (i am at work now). > >> > >> Greetings ! > >> > >> 2010/2/3 > >> > >> > Hello RXTX group, > >> > > >> > I have just joined this group, and this is my first posting. > >> > I wanted to pass on ?some information regarding rxtx, so apologies if > >> > this has been brought up before. I have searched back through the > >> > archives but nothing specific came up. > >> > > >> > I am not a Java programmer, and I only came across rxtx a few days ago. > >> > > >> > I use a piece of test equipment called a miniVNA > >> > http://www.miniradiosolutions.com/ > >> > > >> > This is a serial USB controlled instrument, and it has control software > >> > available for MS windows, and a very old and now non-working Linux > >> > application. > >> > > >> > A few days ago Dietmar, DL2SBA released a Java application to control the > >> > miniVNA, obviously this application makes use of rxtx. > >> > > >> > The program worked fine on Windows, so I set about installing it onto > >> > Linux. I use SUSE11.1 After a few false starts, I got the system running > >> > fairly easily, sorting out the file locking by adding the uucp group to > >> > the users account as suggested (I used the 2.2pre binary files) I then > >> > passed the install instructions onto another miniVNA user, who also uses > >> > SUSE, but he ran into problems. To cut a long story short, he was > >> > also having file lock problems, but the uucp fix did not work. Digging > >> > into his system I found that there have been some changes in SUSE 11.2. > >> > > >> > tty ports are now assigned to the dialout group rather than uucp. > >> > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > >> > checked, so: > >> > > >> > SUSE 11.1, var/lock is root:uucp > >> > SUSE 11.2 var/lock is root:root > >> > > >> > A search on Google brought up several comments regarding this, and also > >> > a ?bugzilla entry. > >> > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > >> > > >> > However from reading the various posts, some of which are in the bugzilla > >> > entry, it appears that many distros may be, or have changed to this > >> > configuration, and this will undoubtedly break several things, rxtx > >> > included. > >> > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the > >> > no lock file option during configure, and that solved his problem. > >> > > >> > As this issue will probably take some time to get resolved across all the > >> > various Linux distros, it might be worth considering changing the default > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > >> > versions of the lib in the binary archive. > >> > > >> > Thanks for your indulgence > >> > > >> > Andy > >> > > >> > _______________________________________________ > >> > Rxtx mailing list > >> > Rxtx at qbang.org > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > >> > >> > >> > >> -- > >> Atte: > >> Daniel Dario Morales Salas > >> Ingeniero Civil en Computaci?n e Inform?tica > >> Tel?fono: 02 684 3417 > >> Celular: 09 643 1802 > >> Santiago, Chile > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > WWW: http://www.sharms.org/blog From damorales at gmail.com Wed Feb 3 18:26:38 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 22:26:38 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100204005829.7dc944e1@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: Hello I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva 2010 this is what i get: drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ and i don't have ANY problem with lock files and RXTX in my java software. All i had to do was add this rule to udev: # serial KERNEL=="tty*", GROUP="uucp", MODE="0666" and that was all. Of course my user (metalklesk) is part of uucp group. I did not make /var/lock writable to all users. Greetings ! 2010/2/3 Andy Eskelson > Thanks Steve, > > changing the serial ports back the uucp is not a big problem. I have a > udev rule that can be easily modified already. However I cannot see any > way of dealing with the var/lock problem apart from making it writable to > all. Any thoughts? > > Andy > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > wrote: > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > and is a result of unified udev rules. You can work around this by > > making udev change the group back to uucp until something more > > happens. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > Thanks, > > > > Steve > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > Thanks Daniel, > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > this for other programs for some time. > > > . > > > I don't think that this is the same problem. as far as I can understand > > > things, the lock files are written in var/lock. Previously var/lock and > > > dev/tty-whatever were the same group. Now with var/lock owned by and > with > > > a group of root:root anything other than root cannot create a lock > > > file. Even minicom is broken by this change. > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > Daniel Morales Salas wrote: > > > > > >> Hi > > >> > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > the uucp > > >> group did not work as it used to be in earlier versions of linux > distros, > > >> causing RXTX to not work as non root user. > > >> > > >> The problem appears because the existense of UDEV, now you MUST add a > RULE > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > the > > >> Serial Port. > > >> > > >> To solve the problem, without needing to recompile RXTX, you must add > a rule > > >> to grant permissions (0666) to the group for the device or port (tty*, > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > i > > >> come back home i will give it to you (i am at work now). > > >> > > >> Greetings ! > > >> > > >> 2010/2/3 > > >> > > >> > Hello RXTX group, > > >> > > > >> > I have just joined this group, and this is my first posting. > > >> > I wanted to pass on some information regarding rxtx, so apologies > if > > >> > this has been brought up before. I have searched back through the > > >> > archives but nothing specific came up. > > >> > > > >> > I am not a Java programmer, and I only came across rxtx a few days > ago. > > >> > > > >> > I use a piece of test equipment called a miniVNA > > >> > http://www.miniradiosolutions.com/ > > >> > > > >> > This is a serial USB controlled instrument, and it has control > software > > >> > available for MS windows, and a very old and now non-working Linux > > >> > application. > > >> > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > control the > > >> > miniVNA, obviously this application makes use of rxtx. > > >> > > > >> > The program worked fine on Windows, so I set about installing it > onto > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > running > > >> > fairly easily, sorting out the file locking by adding the uucp group > to > > >> > the users account as suggested (I used the 2.2pre binary files) I > then > > >> > passed the install instructions onto another miniVNA user, who also > uses > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > >> > also having file lock problems, but the uucp fix did not work. > Digging > > >> > into his system I found that there have been some changes in SUSE > 11.2. > > >> > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > >> > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > >> > checked, so: > > >> > > > >> > SUSE 11.1, var/lock is root:uucp > > >> > SUSE 11.2 var/lock is root:root > > >> > > > >> > A search on Google brought up several comments regarding this, and > also > > >> > a bugzilla entry. > > >> > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > >> > > > >> > However from reading the various posts, some of which are in the > bugzilla > > >> > entry, it appears that many distros may be, or have changed to this > > >> > configuration, and this will undoubtedly break several things, rxtx > > >> > included. > > >> > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > with the > > >> > no lock file option during configure, and that solved his problem. > > >> > > > >> > As this issue will probably take some time to get resolved across > all the > > >> > various Linux distros, it might be worth considering changing the > default > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > >> > versions of the lib in the binary archive. > > >> > > > >> > Thanks for your indulgence > > >> > > > >> > Andy > > >> > > > >> > _______________________________________________ > > >> > Rxtx mailing list > > >> > Rxtx at qbang.org > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > >> > > > >> > > >> > > >> > > >> -- > > >> Atte: > > >> Daniel Dario Morales Salas > > >> Ingeniero Civil en Computaci?n e Inform?tica > > >> Tel?fono: 02 684 3417 > > >> Celular: 09 643 1802 > > >> Santiago, Chile > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at qbang.org > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > -- > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > WWW: http://www.sharms.org/blog > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Thu Feb 4 05:31:46 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 12:31:46 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: <20100204123146.6cffeb67@workstation.site> Thank's for the confirmation. Something odd is going on somewhere in SUSE 11.2. I'll have to build up a local SUSE11.2 system to see if I can nail down exactly what is going on. Something is blocking the lockfiles in var/lock. The net is nice, but it's a bit difficult trying to work out what is going on what the machine in question is in Germany and I'm in the UK :-) Andy On Wed, 3 Feb 2010 22:26:38 -0300 Daniel Morales Salas wrote: > Hello > > I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva > 2010 this is what i get: > > drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ > > and i don't have ANY problem with lock files and RXTX in my java software. > All i had to do was add this rule to udev: > > # serial > KERNEL=="tty*", GROUP="uucp", MODE="0666" > > and that was all. Of course my user (metalklesk) is part of uucp group. > I did not make /var/lock writable to all users. > > Greetings ! > > 2010/2/3 Andy Eskelson > > > Thanks Steve, > > > > changing the serial ports back the uucp is not a big problem. I have a > > udev rule that can be easily modified already. However I cannot see any > > way of dealing with the var/lock problem apart from making it writable to > > all. Any thoughts? > > > > Andy > > > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > > wrote: > > > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > > and is a result of unified udev rules. You can work around this by > > > making udev change the group back to uucp until something more > > > happens. > > > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > > > Thanks, > > > > > > Steve > > > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > > Thanks Daniel, > > > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > > this for other programs for some time. > > > > . > > > > I don't think that this is the same problem. as far as I can understand > > > > things, the lock files are written in var/lock. Previously var/lock and > > > > dev/tty-whatever were the same group. Now with var/lock owned by and > > with > > > > a group of root:root anything other than root cannot create a lock > > > > file. Even minicom is broken by this change. > > > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > > Daniel Morales Salas wrote: > > > > > > > >> Hi > > > >> > > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > > the uucp > > > >> group did not work as it used to be in earlier versions of linux > > distros, > > > >> causing RXTX to not work as non root user. > > > >> > > > >> The problem appears because the existense of UDEV, now you MUST add a > > RULE > > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > > the > > > >> Serial Port. > > > >> > > > >> To solve the problem, without needing to recompile RXTX, you must add > > a rule > > > >> to grant permissions (0666) to the group for the device or port (tty*, > > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > > i > > > >> come back home i will give it to you (i am at work now). > > > >> > > > >> Greetings ! > > > >> > > > >> 2010/2/3 > > > >> > > > >> > Hello RXTX group, > > > >> > > > > >> > I have just joined this group, and this is my first posting. > > > >> > I wanted to pass on some information regarding rxtx, so apologies > > if > > > >> > this has been brought up before. I have searched back through the > > > >> > archives but nothing specific came up. > > > >> > > > > >> > I am not a Java programmer, and I only came across rxtx a few days > > ago. > > > >> > > > > >> > I use a piece of test equipment called a miniVNA > > > >> > http://www.miniradiosolutions.com/ > > > >> > > > > >> > This is a serial USB controlled instrument, and it has control > > software > > > >> > available for MS windows, and a very old and now non-working Linux > > > >> > application. > > > >> > > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > > control the > > > >> > miniVNA, obviously this application makes use of rxtx. > > > >> > > > > >> > The program worked fine on Windows, so I set about installing it > > onto > > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > > running > > > >> > fairly easily, sorting out the file locking by adding the uucp group > > to > > > >> > the users account as suggested (I used the 2.2pre binary files) I > > then > > > >> > passed the install instructions onto another miniVNA user, who also > > uses > > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > > >> > also having file lock problems, but the uucp fix did not work. > > Digging > > > >> > into his system I found that there have been some changes in SUSE > > 11.2. > > > >> > > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > > >> > > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > > >> > checked, so: > > > >> > > > > >> > SUSE 11.1, var/lock is root:uucp > > > >> > SUSE 11.2 var/lock is root:root > > > >> > > > > >> > A search on Google brought up several comments regarding this, and > > also > > > >> > a bugzilla entry. > > > >> > > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > >> > > > > >> > However from reading the various posts, some of which are in the > > bugzilla > > > >> > entry, it appears that many distros may be, or have changed to this > > > >> > configuration, and this will undoubtedly break several things, rxtx > > > >> > included. > > > >> > > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > > with the > > > >> > no lock file option during configure, and that solved his problem. > > > >> > > > > >> > As this issue will probably take some time to get resolved across > > all the > > > >> > various Linux distros, it might be worth considering changing the > > default > > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > > >> > versions of the lib in the binary archive. > > > >> > > > > >> > Thanks for your indulgence > > > >> > > > > >> > Andy > > > >> > > > > >> > _______________________________________________ > > > >> > Rxtx mailing list > > > >> > Rxtx at qbang.org > > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > > >> > > > > >> > > > >> > > > >> > > > >> -- > > > >> Atte: > > > >> Daniel Dario Morales Salas > > > >> Ingeniero Civil en Computaci?n e Inform?tica > > > >> Tel?fono: 02 684 3417 > > > >> Celular: 09 643 1802 > > > >> Santiago, Chile > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at qbang.org > > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > > > -- > > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > > > WWW: http://www.sharms.org/blog > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From Bob_Jacobsen at lbl.gov Thu Feb 4 09:26:49 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Thu, 4 Feb 2010 08:26:49 -0800 Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 Message-ID: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're using RXTX-2.2pre2, although it emits the known message about "Version mismatch". WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 After the usual messing around, we've got it working on 11 Windows versions, multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ have things working rarely say so, so I don't know whether anybody has gotten it to work on 10.4 or not. The problem encountered is this: dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib dyld: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib followed by the JVM crashing hard. I've got those dump files if that would help. Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If so, is there a patch I can get and build? Thanks Bob -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From tjarvi at qbang.org Thu Feb 4 14:22:21 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 4 Feb 2010 14:22:21 -0700 (MST) Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 In-Reply-To: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> References: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> Message-ID: On Thu, 4 Feb 2010, Bob Jacobsen wrote: > We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're > using RXTX-2.2pre2, although it emits the known message about "Version > mismatch". > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > > After the usual messing around, we've got it working on 11 Windows versions, > multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with > a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ > have things working rarely say so, so I don't know whether anybody has gotten > it to work on 10.4 or not. > > The problem encountered is this: > > dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > dyld: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > followed by the JVM crashing hard. I've got those dump files if that would > help. > > Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If > so, is there a patch I can get and build? > Hi Bob, I talked to a coworker about the problem you ran into. It appears that it is possible to target 'older' Mac systems through makefile configuration changes. "Configuring a Makefile-Based Project If you have a makefile-based project, you can also take advantage of SDK-based development, by adding the appropriate options to your compile and link commands. Using SDKs in makefile-based projects requires GCC 4.0 or later. To choose an SDK, you use the -isysroot option with the compiler and the -syslibroot option with the linker. Both options require that you specify the full path to the desired SDK directory. To set the Deployment OS version in a makefile, use a makefile variable of the form: ENVP= MACOSX_DEPLOYMENT_TARGET=10.4. To use this variable in your makefile, include it in front of your compile and link commands." http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html Or build on the oldest system you want to support. -- Trent Jarvi tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Thu Feb 4 14:56:19 2010 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Thu, 4 Feb 2010 14:56:19 -0700 Subject: [Rxtx] RXTX on 64 Bit Redhat In-Reply-To: References: <4ec9eab61001281448g3dd84910r867619948a4e0d7a@mail.gmail.com> Message-ID: Trent -- Finally fixed all my build related issues. I ran into another issue. On one of my machines my JDK is returning multiple folders for the "java.ext.dirs" (java.ext.dirs -> /opt/jdk1.6.0_17/jre/lib/ext:/usr/java/packages/lib/ext) system property. As a result my JVM wasn't able to detect the gnu.io.rxtx.properties. I am attaching a patch for RXTXCommDriver.java file to check for multiple locations. Also i have to assign permission 660 to all my dev ports to be located by RXTX. Pawan ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 5:12 PM To: Trent Jarvi Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Here is the error i get when i build the src from release-2-1-7 -bash-3.2$ make ( \ \ cd i686-pc-linux-gnu; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/ jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I/opt/jav a1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec - c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialImp.lo;\ if [ "Serial" = "Serial" ]; then \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I /opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_tim espec -c /home/jb_stg/rxtx/rxtx-devel/./src/fuserImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ else \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo; \ fi; \ ) gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/inclu de -I/opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need _timespec -c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -fPIC -DPIC -o /hom e/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/.libs/SerialImp.o /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:25:29: error: gnu_io_RXTXPort.h: No such file or directory In file included from /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:113: /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:91: error: expected specifier-qua lifier-list before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'jobject' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:408: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:409: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:410: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:411: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:415: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:416: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:417: error: expected '=', ',', '; ', 'asm' or '__attribute__' before 'is_interrupted' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:418: error: expected declaration specifiers or '...' before 'jint' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:424: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:441: error: expected ')' before ' *' token ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 4:57 PM To: Santosh Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Santosh -- Thank you. That fixed the issue. All -- What CVS branch or release should i use to get the latest RXTX src code. Pawan ________________________________ From: Santosh [mailto:santosh.ry at gmail.com] Sent: Thursday, January 28, 2010 3:49 PM To: Kharbanda, Pawan Cc: Trent Jarvi; rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat error "./configure: /bin/sh^M: bad interpreter: No such file or directory". I think you need to run dos2unix on script files before compiling. Thanks, Santosh On Thu, Jan 28, 2010 at 5:33 PM, Kharbanda, Pawan > wrote: Trent -- We are upgrading our exisiting OS and JDK on a project that rely heavily on RXTX api's. We are now using JDK1.6 32 bit (build 1.6.0_17-b04) and RedHat 5 on a 64 bit machine. Linux tocrhstg02.dot.state.co.us 2.6.18-164.6.1.el5 #1 SMP Tue Oct 27 11:30:06 EDT 2009 i686 i686 i386 GNU/Linux Red Hat Enterprise Linux Server release 5.4 (Tikanga) I tried to run version 2.1.7 r2 on it but not able to see any of my Digi ports I was able to access only /dev/ttyS0 (physical ports). Not sure if the problem is with the Digi driver or RXTX. I tried to open a Digi port with minicom and it worked fine. I also tried to get latest from CVS (rxtx-devel) and when I do "configure" I see this error "./configure: /bin/sh^M: bad interpreter: No such file or directory". Can someone please help me with this? Thanks for the help. Pawan _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch.txt URL: From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 01:02:21 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 13:32:21 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> My serial port driver(apparently) does not support receive timeout.I registered an event listener for DATA_AVAILABLE. However, the control never seems to come out of the 'while' loop.Shouldn't the InputStream.read return a '-1' immediately if no data is available (this seems to be the default operation)? This was tried on a x86 Linux desktop using rxtx-2.1-7 I've added the snippet for clarity: /******************************************************************************************************************************************************************************/ mySerialPort.enableReceiveThreshold(2000);//Trying to set a time limit for read calls System.out.println(mySerialPort.isReceiveTimeoutEnabled()); // I get FALSE, so its not supported on hardware. mySerialPort.addEventListener(this); mySerialPort.notifyOnDataAvailable(true);//register a event with //my SerialEvent listener implementation: public void serialEvent(SerialPortEvent arg0) { int newData=0; switch(arg0.getEventType()){ case SerialPortEvent.DATA_AVAILABLE: while (newData != -1) { try { newData = is.read();//This should eventually return a -1 if no data is available within a timeout.PROBLEM!! System.out.println("Got a byte from port:"+newData); if (newData == -1) { break; } } catch (IOException ex) { System.err.println(ex); return; } } break; } return; } /******************************************************************************************************************************************************************************/ Thanks and regards, Ravi From michael.erskine at ketech.com Wed Feb 3 02:26:50 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 09:26:50 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From michael.erskine at ketech.com Wed Feb 3 05:03:30 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 12:03:30 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > Michael Erskine > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > > Your event handler should handle the event and return immediately so that its > controlling thread can handle other events. I recommend a single read in the > following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) > reads all available bytes up to the size of the buffer returning the number of > bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } After posting this I considered the glaring possibility of the rawbuf read buffer being too small to receive all the available bytes and perhaps skipping data: after all, I'm guessing that is why we see so many posts asking for help with blocking implementations of read event handlers looping on "while(bytes are available)". I've spent this morning writing an extensive multi-threaded unit test suite that includes tests with a tiny buffer compared to the amount of data available and found that no data was being skipped. I now want to know why! The SerialPortEvent.DATA_AVAILABLE event must be being fired again if there is more data available on the input stream. If that is the case then it should be heavily documented with good examples in the wiki to avoid the types of developer anguish we see so regularly. BTW: I'm not at liberty to post the JUnit tests as they use my company's unit test suite framework. Regards, Michael Erskine. From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 06:18:04 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 18:48:04 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Hello Michael, I tried out your suggestion but the problem is that the read(rawbuf) blocks until the entire length of the rawbuf array has been read (blocking). I cannot decide on a reasonable size of the array because it varies from 2 bytes to as much as 50 byes (i'm communicating with a modem,each response is of a different length), which is why i wanted to use non blocking calls. But on a side note, read(byte[]) in turn calls the read() in a loop.In the native C function, the read is supposed to return a -1 upon timeout.But my driver does not support timeout.The default timeout value is zero and the linux select call upon zero time out causes an infinite wait.What am i missing...... Thanks and regards, Ravi Date: Wed, 3 Feb 2010 09:26:50 +0000 From: Michael Erskine To: "rxtx at qbang.org" Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: Content-Type: text/plain; charset="us-ascii" > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From m.kirkland at comcast.net Wed Feb 3 06:46:03 2010 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 3 Feb 2010 05:46:03 -0800 Subject: [Rxtx] One port blocking another port In-Reply-To: References: Message-ID: <68768633814F4D7D86761D34F0764FE0@bengal.net> It turns out this is caused by having the RTS/CTS flow control turned on and me not providing a true on the RTS pin. Somehow it seems the port timing out on a read allows the write to proceed. This is not an issue for my application but I wonder if the write should not proceed until the RTS pin is true even if a read times out. mk -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Monday, January 25, 2010 7:48 PM To: Mike Kirkland Cc: rxtx at qbang.org Subject: Re: [Rxtx] One port blocking another port On Mon, 25 Jan 2010, Mike Kirkland wrote: > > Hi All, > > ? > > I have a program that reads from one com port and writes to another com > port. It also does the same thing in reverse (reads from the second com port > and writes to the first one. It basically ties two com ports together. > > ? > > One port is very chatty and has a consent stream of data. The other port has > very little data. > > ? > > Both ports use a 5000 ms (5 second) time out. > > ? > > The issue I am having is that is appears that the first port?s write to the > second port is blocked while the second port is waiting for input. The first > port?s write proceeds only after the second port has timed out. > > ? > > I suppose I could have something twisted around in my code but I was > wondering if this is a know issue? > Hi Kirk, I've not seen a report like this. Perhaps some simple reproduction code will reveal a problem on your end or help us identify a problem in rxtx. I think there are several users doing multiport communication. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Wed Feb 3 07:03:58 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:03:58 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Message-ID: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> 2010/2/3 Ravishankar N > Hello Michael, > [..] > But on a side note, read(byte[]) in turn calls the read() in a loop.In the > native C function, the read is supposed to return a -1 upon timeout.But my > driver > does not support timeout.The default timeout value is zero and the linux > select call upon zero time out causes an infinite wait.What am i > missing...... > > When I have tested RXTX between platforms, I have observed "hangup" inside JNI driver when no data in Linux, is normal thing. Solution was setting the timeout for RXTX when no data from JNI driver. Something like that: commPort.enableReceiveTimeout(10); And it works perfect.... The only difference is that I am NOT using events - I am using continous read in separate thread and if data is available, is parsed and transferred to application using exception. Regards Mariusz > Thanks and regards, > Ravi > > Date: Wed, 3 Feb 2010 09:26:50 +0000 > From: Michael Erskine > To: "rxtx at qbang.org" > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > Message-ID: > > > Content-Type: text/plain; charset="us-ascii" > > > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of > > Ravishankar N > > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > > > My serial port driver(apparently) does not support receive timeout.I > > registered an event listener for DATA_AVAILABLE. However, the control > never > > seems to come out of the 'while' loop.Shouldn't the > > InputStream.read return a '-1' immediately if no data is available (this > seems > > to be the default operation)? > > Your event handler should handle the event and return immediately so that > its controlling thread can handle other events. I recommend a single read in > the following manner: rawbuf is a byte[] of "reasonable" size and the > read(byte[]) reads all available bytes up to the size of the buffer > returning the number of bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } > > This style of reading has worked for me with RXTX on Linux and Windows XP > for a good few years now in railway industry communications systems. Any > timeouts (largely unnecessary in my applications) can be handled elsewhere, > usually at a higher layer. > > Regards, > Michael Erskine. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Feb 3 07:22:55 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 3 Feb 2010 09:22:55 -0500 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: I'm guessing that this is driver specific. I recently had to support a select()/poll() infrastructure for a linux serial DD, its certainly non trivial to support async IO, so I suspect the problem in this case has to do with missing poll infrastructure in the device driver. This also has to coupled with special open flags for the device (which is within the rxtx code) The key routines within a 2.6 kernel linux device driver are shown below (if you have access to it for your particular device) are indicated below (here is a snippet from my device driver c code that supports polling/select). User space code to test this shown below also, note that the device needs to be opened with the O_NONBLOCK option to support the select/poll api // device driver code ..... /* * File operations supported by this driver. */ static struct file_operations iop_fops = { .owner = THIS_MODULE, .check_flags= iop_check_flags, .ioctl = iop_ioctl, .open = iop_open, .poll = iop_poll, // SUPPORT FOR SELECT/POLL infrastructure .read = iop_read, .release = iop_release, .write = iop_write, }; /** * Select/poll/epoll infrastructure. * * @param file * @param wait * * @return */ static unsigned int iop_poll(struct file *filp, poll_table *wait) { struct iop_device *devp = (struct iop_device *)filp->private_data; // the poll_table wait arg is an opaque pointer poll_wait(filp, &devp->readq, wait); // return from poll indicating whether we have read/write data unsigned int mask = 0; if (kfifo_len(devp->rx_fifo)) { mask |= (POLLIN | POLLRDNORM); } // @JC We don't do select on write yet // if (kfifo_len(devp->tx_fifo)) { // mask |= (POLLOUT | POLLWRNORM); // } // Only print out while debugging // if (mask != 0) { // printk (KERN_INFO "%s: [%04x]\n", __FUNCTION__, mask); // } return mask; } /** * device driver blocking and non blocking read function. This * function reads the requested number of bytes from the read * kfifo blocking as required. * * @param filp * @param buf * @param count * @param f_pos * * @return */ static ssize_t iop_read(struct file *filp, char __user *buf, size_t count, loff_t * ppos) { // access appropriate device struct struct iop_device *devp = (struct iop_device *) filp->private_data; ssize_t retval; // support non blocking mode (default) by checking if the kfifo is empty first if ((kfifo_len(devp->rx_fifo)==0) && (filp->f_flags & O_NONBLOCK)) { return -EAGAIN; } // wait for rx_fifo to receive data via receive interrupts retval = wait_event_interruptible(devp->readq, kfifo_len(devp->rx_fifo) != 0); // check for some error condition if (retval) { printk (KERN_ERR "%s: wait_event_interruptible returned[%d]\n", __FUNCTION__, retval); return retval; } // copy max requested bytes from rx_fifo to device buffer // this may still leave bytes in the kfifo for a subsequent read // if we are reading in a loop retval = kfifo_get(devp->rx_fifo, devp->rxbuf, count); // printk (KERN_INFO "%s: [%d] byte(s)\n", __FUNCTION__, retval); if (copy_to_user(buf, devp->rxbuf, retval)) { printk (KERN_ERR "%s: problem copying rx_fifo data to user buffer\n", __FUNCTION__); return -EFAULT; } return retval; } // a selection of my user space code reading via select()/poll()..... // user space open code iop_fd = ::open( deviceName.data(), O_RDWR | O_NONBLOCK); while ((bytes_to_expect - bytes_read) > 0) { // must reinitialize these between select calls fd_set readfds; FD_ZERO( &readfds ); FD_SET( iop_fd, &readfds ); // 1s sec read polling timeout struct timeval timeout; timeout.tv_sec = 1; timeout.tv_usec = 0; int rc = select( FD_SETSIZE, &readfds, NULL, NULL, &timeout ); // read from file when descriptor // indicates data available without blocking if ((rc > 0) && FD_ISSET(iop_fd, &readfds)) { // read into the appropriate offset within the rx_buf int temp = read(iop_fd, rx_buf + bytes_read, bytes_to_expect - bytes_read); if (!temp) { printf("EOF detected with %d bytes expected\n", bytes_to_expect - bytes_read); } else { bytes_read += temp; } } else if (rc < 0){ printf("%s: select on [%s], bytes_read[%d], errno=%d\n", __FUNCTION__, thread_args->device, bytes_read, errno); } else { printf("%s: select on [%s], bytes_read[%d], timeout\n", __FUNCTION__, thread_args->device, bytes_read); } } On Wed, Feb 3, 2010 at 9:03 AM, Mariusz Dec wrote: > > > 2010/2/3 Ravishankar N > >> Hello Michael, >> [..] >> >> But on a side note, read(byte[]) in turn calls the read() in a loop.In the >> native C function, the read is supposed to return a -1 upon timeout.But my >> driver >> does not support timeout.The default timeout value is zero and the linux >> select call upon zero time out causes an infinite wait.What am i >> missing...... >> >> > When I have tested RXTX between platforms, I have observed "hangup" inside > JNI driver when no data in Linux, is normal thing. > > Solution was setting the timeout for RXTX when no data from JNI driver. > > Something like that: > > commPort.enableReceiveTimeout(10); > > And it works perfect.... > > The only difference is that I am NOT using events - I am using continous > read in separate thread and if data is available, is parsed and transferred > to application using exception. > > Regards > Mariusz > > > >> Thanks and regards, >> Ravi >> >> Date: Wed, 3 Feb 2010 09:26:50 +0000 >> From: Michael Erskine >> To: "rxtx at qbang.org" >> Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? >> Message-ID: >> >> >> Content-Type: text/plain; charset="us-ascii" >> >> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >> Of >> > Ravishankar N >> > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? >> > >> > My serial port driver(apparently) does not support receive timeout.I >> > registered an event listener for DATA_AVAILABLE. However, the control >> never >> > seems to come out of the 'while' loop.Shouldn't the >> > InputStream.read return a '-1' immediately if no data is available (this >> seems >> > to be the default operation)? >> >> Your event handler should handle the event and return immediately so that >> its controlling thread can handle other events. I recommend a single read in >> the following manner: rawbuf is a byte[] of "reasonable" size and the >> read(byte[]) reads all available bytes up to the size of the buffer >> returning the number of bytes actually read... >> >> case SerialPortEvent.DATA_AVAILABLE: >> try { >> int i = is.read(rawbuf); >> if (i == -1) { >> << process EOF condition - should never happen >> >> return; >> } >> << process bytes (rawbuf, i); >> >> return; >> } catch (IOException e) { >> << promptly deal with exception >> >> return; >> } >> >> This style of reading has worked for me with RXTX on Linux and Windows XP >> for a good few years now in railway industry communications systems. Any >> timeouts (largely unnecessary in my applications) can be handled elsewhere, >> usually at a higher layer. >> >> Regards, >> Michael Erskine. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Feb 3 07:33:27 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:33:27 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: <73a89f361002030633j682610afia48dc7accd8e049b@mail.gmail.com> 2010/2/3 John Coffey > I'm guessing that this is driver specific. I recently had to support a > select()/poll() infrastructure for a linux serial DD, its certainly non > trivial to support async IO, so I suspect the problem in this case has to do > with missing poll infrastructure in the device driver. This also has to > coupled with special open flags for the device (which is within the rxtx > code) > > Yes, you are right, it may be driver specific, but in my case I haven't changed blocking JNI driver. I have added ONLY one call to RXTX method mentioned in my previous post and blocking (as seen as from Java app) gone out... Maybe this is not elegant, but works without problem in my app. I am using only FTDI chips and their drivers from couple of years and maybe this is the kind of the way to have no many problems with serial as well? Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From andyrxtx at g0poy.co.uk Wed Feb 3 11:09:04 2010 From: andyrxtx at g0poy.co.uk (andyrxtx at g0poy.co.uk) Date: Wed, 3 Feb 2010 18:09:04 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes Message-ID: <20100203180904.164f24dd@workstation.site> ?Hello RXTX group, I have just joined this group, and this is my first posting. I wanted to pass on some information regarding rxtx, so apologies if this has been brought up before. I have searched back through the archives but nothing specific came up. I am not a Java programmer, and I only came across rxtx a few days ago. I use a piece of test equipment called a miniVNA http://www.miniradiosolutions.com/ This is a serial USB controlled instrument, and it has control software available for MS windows, and a very old and now non-working Linux application. A few days ago Dietmar, DL2SBA released a Java application to control the miniVNA, obviously this application makes use of rxtx. The program worked fine on Windows, so I set about installing it onto Linux. I use SUSE11.1 After a few false starts, I got the system running fairly easily, sorting out the file locking by adding the uucp group to the users account as suggested (I used the 2.2pre binary files) I then passed the install instructions onto another miniVNA user, who also uses SUSE, but he ran into problems. To cut a long story short, he was also having file lock problems, but the uucp fix did not work. Digging into his system I found that there have been some changes in SUSE 11.2. tty ports are now assigned to the dialout group rather than uucp. A hint in the rxtx INSTALL file, suggested that var/lock needs to be checked, so: SUSE 11.1, var/lock is root:uucp SUSE 11.2 var/lock is root:root A search on Google brought up several comments regarding this, and also a bugzilla entry. https://bugzilla.novell.com/show_bug.cgi?id=552095 However from reading the various posts, some of which are in the bugzilla entry, it appears that many distros may be, or have changed to this configuration, and this will undoubtedly break several things, rxtx included. I solved my fellow SUSE users problem by compiling the rxtx libs with the no lock file option during configure, and that solved his problem. As this issue will probably take some time to get resolved across all the various Linux distros, it might be worth considering changing the default on the Linux build of rxtx not to use lockfiles, or provide the two versions of the lib in the binary archive. Thanks for your indulgence Andy From damorales at gmail.com Wed Feb 3 11:33:23 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 15:33:23 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203180904.164f24dd@workstation.site> References: <20100203180904.164f24dd@workstation.site> Message-ID: Hi I had the same problem in Mandriva 2010 and yes, adding the user to the uucp group did not work as it used to be in earlier versions of linux distros, causing RXTX to not work as non root user. The problem appears because the existense of UDEV, now you MUST add a RULE so the group (uucp or whatever) have access (Read, Write, Execute) to the Serial Port. To solve the problem, without needing to recompile RXTX, you must add a rule to grant permissions (0666) to the group for the device or port (tty*, ttyUSB*, etc). I do not remember now what is the line i added but when i come back home i will give it to you (i am at work now). Greetings ! 2010/2/3 > Hello RXTX group, > > I have just joined this group, and this is my first posting. > I wanted to pass on some information regarding rxtx, so apologies if > this has been brought up before. I have searched back through the > archives but nothing specific came up. > > I am not a Java programmer, and I only came across rxtx a few days ago. > > I use a piece of test equipment called a miniVNA > http://www.miniradiosolutions.com/ > > This is a serial USB controlled instrument, and it has control software > available for MS windows, and a very old and now non-working Linux > application. > > A few days ago Dietmar, DL2SBA released a Java application to control the > miniVNA, obviously this application makes use of rxtx. > > The program worked fine on Windows, so I set about installing it onto > Linux. I use SUSE11.1 After a few false starts, I got the system running > fairly easily, sorting out the file locking by adding the uucp group to > the users account as suggested (I used the 2.2pre binary files) I then > passed the install instructions onto another miniVNA user, who also uses > SUSE, but he ran into problems. To cut a long story short, he was > also having file lock problems, but the uucp fix did not work. Digging > into his system I found that there have been some changes in SUSE 11.2. > > tty ports are now assigned to the dialout group rather than uucp. > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > checked, so: > > SUSE 11.1, var/lock is root:uucp > SUSE 11.2 var/lock is root:root > > A search on Google brought up several comments regarding this, and also > a bugzilla entry. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > However from reading the various posts, some of which are in the bugzilla > entry, it appears that many distros may be, or have changed to this > configuration, and this will undoubtedly break several things, rxtx > included. > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > no lock file option during configure, and that solved his problem. > > As this issue will probably take some time to get resolved across all the > various Linux distros, it might be worth considering changing the default > on the Linux build of rxtx not to use lockfiles, or provide the two > versions of the lib in the binary archive. > > Thanks for your indulgence > > Andy > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Wed Feb 3 12:07:02 2010 From: andy at g0poy.com (Andy Eskelson) Date: Wed, 3 Feb 2010 19:07:02 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> Message-ID: <20100203190702.1b0e7015@workstation.site> Thanks Daniel, I am aware of the permissions problem, I have had a udev rules to solve this for other programs for some time. . I don't think that this is the same problem. as far as I can understand things, the lock files are written in var/lock. Previously var/lock and dev/tty-whatever were the same group. Now with var/lock owned by and with a group of root:root anything other than root cannot create a lock file. Even minicom is broken by this change. This change is going to have quite a few knock-on effects I think. Andy On Wed, 3 Feb 2010 15:33:23 -0300 Daniel Morales Salas wrote: > Hi > > I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > group did not work as it used to be in earlier versions of linux distros, > causing RXTX to not work as non root user. > > The problem appears because the existense of UDEV, now you MUST add a RULE > so the group (uucp or whatever) have access (Read, Write, Execute) to the > Serial Port. > > To solve the problem, without needing to recompile RXTX, you must add a rule > to grant permissions (0666) to the group for the device or port (tty*, > ttyUSB*, etc). I do not remember now what is the line i added but when i > come back home i will give it to you (i am at work now). > > Greetings ! > > 2010/2/3 > > > Hello RXTX group, > > > > I have just joined this group, and this is my first posting. > > I wanted to pass on some information regarding rxtx, so apologies if > > this has been brought up before. I have searched back through the > > archives but nothing specific came up. > > > > I am not a Java programmer, and I only came across rxtx a few days ago. > > > > I use a piece of test equipment called a miniVNA > > http://www.miniradiosolutions.com/ > > > > This is a serial USB controlled instrument, and it has control software > > available for MS windows, and a very old and now non-working Linux > > application. > > > > A few days ago Dietmar, DL2SBA released a Java application to control the > > miniVNA, obviously this application makes use of rxtx. > > > > The program worked fine on Windows, so I set about installing it onto > > Linux. I use SUSE11.1 After a few false starts, I got the system running > > fairly easily, sorting out the file locking by adding the uucp group to > > the users account as suggested (I used the 2.2pre binary files) I then > > passed the install instructions onto another miniVNA user, who also uses > > SUSE, but he ran into problems. To cut a long story short, he was > > also having file lock problems, but the uucp fix did not work. Digging > > into his system I found that there have been some changes in SUSE 11.2. > > > > tty ports are now assigned to the dialout group rather than uucp. > > > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > checked, so: > > > > SUSE 11.1, var/lock is root:uucp > > SUSE 11.2 var/lock is root:root > > > > A search on Google brought up several comments regarding this, and also > > a bugzilla entry. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > However from reading the various posts, some of which are in the bugzilla > > entry, it appears that many distros may be, or have changed to this > > configuration, and this will undoubtedly break several things, rxtx > > included. > > > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > > no lock file option during configure, and that solved his problem. > > > > As this issue will probably take some time to get resolved across all the > > various Linux distros, it might be worth considering changing the default > > on the Linux build of rxtx not to use lockfiles, or provide the two > > versions of the lib in the binary archive. > > > > Thanks for your indulgence > > > > Andy > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From thisdyingdream at gmail.com Wed Feb 3 12:32:35 2010 From: thisdyingdream at gmail.com (Steven Harms) Date: Wed, 3 Feb 2010 14:32:35 -0500 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203190702.1b0e7015@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: This is currently a bug in OpenSUSE that affects more than just rxtx, and is a result of unified udev rules. You can work around this by making udev change the group back to uucp until something more happens. https://bugzilla.novell.com/show_bug.cgi?id=552095 Thanks, Steve On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > Thanks Daniel, > > I am aware of the permissions problem, I have had a udev rules to solve > this for other programs for some time. > . > I don't think that this is the same problem. as far as I can understand > things, the lock files are written in var/lock. Previously var/lock and > dev/tty-whatever were the same group. Now with var/lock owned by and with > a group of root:root anything other than root cannot create a lock > file. Even minicom is broken by this change. > > This change is going to have quite a few knock-on effects I think. > > > Andy > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > Daniel Morales Salas wrote: > >> Hi >> >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp >> group did not work as it used to be in earlier versions of linux distros, >> causing RXTX to not work as non root user. >> >> The problem appears because the existense of UDEV, now you MUST add a RULE >> so the group (uucp or whatever) have access (Read, Write, Execute) to the >> Serial Port. >> >> To solve the problem, without needing to recompile RXTX, you must add a rule >> to grant permissions (0666) to the group for the device or port (tty*, >> ttyUSB*, etc). I do not remember now what is the line i added but when i >> come back home i will give it to you (i am at work now). >> >> Greetings ! >> >> 2010/2/3 >> >> > Hello RXTX group, >> > >> > I have just joined this group, and this is my first posting. >> > I wanted to pass on ?some information regarding rxtx, so apologies if >> > this has been brought up before. I have searched back through the >> > archives but nothing specific came up. >> > >> > I am not a Java programmer, and I only came across rxtx a few days ago. >> > >> > I use a piece of test equipment called a miniVNA >> > http://www.miniradiosolutions.com/ >> > >> > This is a serial USB controlled instrument, and it has control software >> > available for MS windows, and a very old and now non-working Linux >> > application. >> > >> > A few days ago Dietmar, DL2SBA released a Java application to control the >> > miniVNA, obviously this application makes use of rxtx. >> > >> > The program worked fine on Windows, so I set about installing it onto >> > Linux. I use SUSE11.1 After a few false starts, I got the system running >> > fairly easily, sorting out the file locking by adding the uucp group to >> > the users account as suggested (I used the 2.2pre binary files) I then >> > passed the install instructions onto another miniVNA user, who also uses >> > SUSE, but he ran into problems. To cut a long story short, he was >> > also having file lock problems, but the uucp fix did not work. Digging >> > into his system I found that there have been some changes in SUSE 11.2. >> > >> > tty ports are now assigned to the dialout group rather than uucp. >> > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be >> > checked, so: >> > >> > SUSE 11.1, var/lock is root:uucp >> > SUSE 11.2 var/lock is root:root >> > >> > A search on Google brought up several comments regarding this, and also >> > a ?bugzilla entry. >> > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 >> > >> > However from reading the various posts, some of which are in the bugzilla >> > entry, it appears that many distros may be, or have changed to this >> > configuration, and this will undoubtedly break several things, rxtx >> > included. >> > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the >> > no lock file option during configure, and that solved his problem. >> > >> > As this issue will probably take some time to get resolved across all the >> > various Linux distros, it might be worth considering changing the default >> > on the Linux build of rxtx not to use lockfiles, or provide the two >> > versions of the lib in the binary archive. >> > >> > Thanks for your indulgence >> > >> > Andy >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> >> >> >> -- >> Atte: >> Daniel Dario Morales Salas >> Ingeniero Civil en Computaci?n e Inform?tica >> Tel?fono: 02 684 3417 >> Celular: 09 643 1802 >> Santiago, Chile > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 WWW: http://www.sharms.org/blog From andy at g0poy.com Wed Feb 3 17:58:29 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 00:58:29 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: <20100204005829.7dc944e1@workstation.site> Thanks Steve, changing the serial ports back the uucp is not a big problem. I have a udev rule that can be easily modified already. However I cannot see any way of dealing with the var/lock problem apart from making it writable to all. Any thoughts? Andy On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms wrote: > This is currently a bug in OpenSUSE that affects more than just rxtx, > and is a result of unified udev rules. You can work around this by > making udev change the group back to uucp until something more > happens. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > Thanks, > > Steve > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > Thanks Daniel, > > > > I am aware of the permissions problem, I have had a udev rules to solve > > this for other programs for some time. > > . > > I don't think that this is the same problem. as far as I can understand > > things, the lock files are written in var/lock. Previously var/lock and > > dev/tty-whatever were the same group. Now with var/lock owned by and with > > a group of root:root anything other than root cannot create a lock > > file. Even minicom is broken by this change. > > > > This change is going to have quite a few knock-on effects I think. > > > > > > Andy > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > Daniel Morales Salas wrote: > > > >> Hi > >> > >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > >> group did not work as it used to be in earlier versions of linux distros, > >> causing RXTX to not work as non root user. > >> > >> The problem appears because the existense of UDEV, now you MUST add a RULE > >> so the group (uucp or whatever) have access (Read, Write, Execute) to the > >> Serial Port. > >> > >> To solve the problem, without needing to recompile RXTX, you must add a rule > >> to grant permissions (0666) to the group for the device or port (tty*, > >> ttyUSB*, etc). I do not remember now what is the line i added but when i > >> come back home i will give it to you (i am at work now). > >> > >> Greetings ! > >> > >> 2010/2/3 > >> > >> > Hello RXTX group, > >> > > >> > I have just joined this group, and this is my first posting. > >> > I wanted to pass on ?some information regarding rxtx, so apologies if > >> > this has been brought up before. I have searched back through the > >> > archives but nothing specific came up. > >> > > >> > I am not a Java programmer, and I only came across rxtx a few days ago. > >> > > >> > I use a piece of test equipment called a miniVNA > >> > http://www.miniradiosolutions.com/ > >> > > >> > This is a serial USB controlled instrument, and it has control software > >> > available for MS windows, and a very old and now non-working Linux > >> > application. > >> > > >> > A few days ago Dietmar, DL2SBA released a Java application to control the > >> > miniVNA, obviously this application makes use of rxtx. > >> > > >> > The program worked fine on Windows, so I set about installing it onto > >> > Linux. I use SUSE11.1 After a few false starts, I got the system running > >> > fairly easily, sorting out the file locking by adding the uucp group to > >> > the users account as suggested (I used the 2.2pre binary files) I then > >> > passed the install instructions onto another miniVNA user, who also uses > >> > SUSE, but he ran into problems. To cut a long story short, he was > >> > also having file lock problems, but the uucp fix did not work. Digging > >> > into his system I found that there have been some changes in SUSE 11.2. > >> > > >> > tty ports are now assigned to the dialout group rather than uucp. > >> > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > >> > checked, so: > >> > > >> > SUSE 11.1, var/lock is root:uucp > >> > SUSE 11.2 var/lock is root:root > >> > > >> > A search on Google brought up several comments regarding this, and also > >> > a ?bugzilla entry. > >> > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > >> > > >> > However from reading the various posts, some of which are in the bugzilla > >> > entry, it appears that many distros may be, or have changed to this > >> > configuration, and this will undoubtedly break several things, rxtx > >> > included. > >> > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the > >> > no lock file option during configure, and that solved his problem. > >> > > >> > As this issue will probably take some time to get resolved across all the > >> > various Linux distros, it might be worth considering changing the default > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > >> > versions of the lib in the binary archive. > >> > > >> > Thanks for your indulgence > >> > > >> > Andy > >> > > >> > _______________________________________________ > >> > Rxtx mailing list > >> > Rxtx at qbang.org > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > >> > >> > >> > >> -- > >> Atte: > >> Daniel Dario Morales Salas > >> Ingeniero Civil en Computaci?n e Inform?tica > >> Tel?fono: 02 684 3417 > >> Celular: 09 643 1802 > >> Santiago, Chile > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > WWW: http://www.sharms.org/blog From damorales at gmail.com Wed Feb 3 18:26:38 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 22:26:38 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100204005829.7dc944e1@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: Hello I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva 2010 this is what i get: drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ and i don't have ANY problem with lock files and RXTX in my java software. All i had to do was add this rule to udev: # serial KERNEL=="tty*", GROUP="uucp", MODE="0666" and that was all. Of course my user (metalklesk) is part of uucp group. I did not make /var/lock writable to all users. Greetings ! 2010/2/3 Andy Eskelson > Thanks Steve, > > changing the serial ports back the uucp is not a big problem. I have a > udev rule that can be easily modified already. However I cannot see any > way of dealing with the var/lock problem apart from making it writable to > all. Any thoughts? > > Andy > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > wrote: > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > and is a result of unified udev rules. You can work around this by > > making udev change the group back to uucp until something more > > happens. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > Thanks, > > > > Steve > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > Thanks Daniel, > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > this for other programs for some time. > > > . > > > I don't think that this is the same problem. as far as I can understand > > > things, the lock files are written in var/lock. Previously var/lock and > > > dev/tty-whatever were the same group. Now with var/lock owned by and > with > > > a group of root:root anything other than root cannot create a lock > > > file. Even minicom is broken by this change. > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > Daniel Morales Salas wrote: > > > > > >> Hi > > >> > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > the uucp > > >> group did not work as it used to be in earlier versions of linux > distros, > > >> causing RXTX to not work as non root user. > > >> > > >> The problem appears because the existense of UDEV, now you MUST add a > RULE > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > the > > >> Serial Port. > > >> > > >> To solve the problem, without needing to recompile RXTX, you must add > a rule > > >> to grant permissions (0666) to the group for the device or port (tty*, > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > i > > >> come back home i will give it to you (i am at work now). > > >> > > >> Greetings ! > > >> > > >> 2010/2/3 > > >> > > >> > Hello RXTX group, > > >> > > > >> > I have just joined this group, and this is my first posting. > > >> > I wanted to pass on some information regarding rxtx, so apologies > if > > >> > this has been brought up before. I have searched back through the > > >> > archives but nothing specific came up. > > >> > > > >> > I am not a Java programmer, and I only came across rxtx a few days > ago. > > >> > > > >> > I use a piece of test equipment called a miniVNA > > >> > http://www.miniradiosolutions.com/ > > >> > > > >> > This is a serial USB controlled instrument, and it has control > software > > >> > available for MS windows, and a very old and now non-working Linux > > >> > application. > > >> > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > control the > > >> > miniVNA, obviously this application makes use of rxtx. > > >> > > > >> > The program worked fine on Windows, so I set about installing it > onto > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > running > > >> > fairly easily, sorting out the file locking by adding the uucp group > to > > >> > the users account as suggested (I used the 2.2pre binary files) I > then > > >> > passed the install instructions onto another miniVNA user, who also > uses > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > >> > also having file lock problems, but the uucp fix did not work. > Digging > > >> > into his system I found that there have been some changes in SUSE > 11.2. > > >> > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > >> > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > >> > checked, so: > > >> > > > >> > SUSE 11.1, var/lock is root:uucp > > >> > SUSE 11.2 var/lock is root:root > > >> > > > >> > A search on Google brought up several comments regarding this, and > also > > >> > a bugzilla entry. > > >> > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > >> > > > >> > However from reading the various posts, some of which are in the > bugzilla > > >> > entry, it appears that many distros may be, or have changed to this > > >> > configuration, and this will undoubtedly break several things, rxtx > > >> > included. > > >> > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > with the > > >> > no lock file option during configure, and that solved his problem. > > >> > > > >> > As this issue will probably take some time to get resolved across > all the > > >> > various Linux distros, it might be worth considering changing the > default > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > >> > versions of the lib in the binary archive. > > >> > > > >> > Thanks for your indulgence > > >> > > > >> > Andy > > >> > > > >> > _______________________________________________ > > >> > Rxtx mailing list > > >> > Rxtx at qbang.org > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > >> > > > >> > > >> > > >> > > >> -- > > >> Atte: > > >> Daniel Dario Morales Salas > > >> Ingeniero Civil en Computaci?n e Inform?tica > > >> Tel?fono: 02 684 3417 > > >> Celular: 09 643 1802 > > >> Santiago, Chile > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at qbang.org > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > -- > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > WWW: http://www.sharms.org/blog > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Thu Feb 4 05:31:46 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 12:31:46 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: <20100204123146.6cffeb67@workstation.site> Thank's for the confirmation. Something odd is going on somewhere in SUSE 11.2. I'll have to build up a local SUSE11.2 system to see if I can nail down exactly what is going on. Something is blocking the lockfiles in var/lock. The net is nice, but it's a bit difficult trying to work out what is going on what the machine in question is in Germany and I'm in the UK :-) Andy On Wed, 3 Feb 2010 22:26:38 -0300 Daniel Morales Salas wrote: > Hello > > I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva > 2010 this is what i get: > > drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ > > and i don't have ANY problem with lock files and RXTX in my java software. > All i had to do was add this rule to udev: > > # serial > KERNEL=="tty*", GROUP="uucp", MODE="0666" > > and that was all. Of course my user (metalklesk) is part of uucp group. > I did not make /var/lock writable to all users. > > Greetings ! > > 2010/2/3 Andy Eskelson > > > Thanks Steve, > > > > changing the serial ports back the uucp is not a big problem. I have a > > udev rule that can be easily modified already. However I cannot see any > > way of dealing with the var/lock problem apart from making it writable to > > all. Any thoughts? > > > > Andy > > > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > > wrote: > > > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > > and is a result of unified udev rules. You can work around this by > > > making udev change the group back to uucp until something more > > > happens. > > > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > > > Thanks, > > > > > > Steve > > > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > > Thanks Daniel, > > > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > > this for other programs for some time. > > > > . > > > > I don't think that this is the same problem. as far as I can understand > > > > things, the lock files are written in var/lock. Previously var/lock and > > > > dev/tty-whatever were the same group. Now with var/lock owned by and > > with > > > > a group of root:root anything other than root cannot create a lock > > > > file. Even minicom is broken by this change. > > > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > > Daniel Morales Salas wrote: > > > > > > > >> Hi > > > >> > > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > > the uucp > > > >> group did not work as it used to be in earlier versions of linux > > distros, > > > >> causing RXTX to not work as non root user. > > > >> > > > >> The problem appears because the existense of UDEV, now you MUST add a > > RULE > > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > > the > > > >> Serial Port. > > > >> > > > >> To solve the problem, without needing to recompile RXTX, you must add > > a rule > > > >> to grant permissions (0666) to the group for the device or port (tty*, > > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > > i > > > >> come back home i will give it to you (i am at work now). > > > >> > > > >> Greetings ! > > > >> > > > >> 2010/2/3 > > > >> > > > >> > Hello RXTX group, > > > >> > > > > >> > I have just joined this group, and this is my first posting. > > > >> > I wanted to pass on some information regarding rxtx, so apologies > > if > > > >> > this has been brought up before. I have searched back through the > > > >> > archives but nothing specific came up. > > > >> > > > > >> > I am not a Java programmer, and I only came across rxtx a few days > > ago. > > > >> > > > > >> > I use a piece of test equipment called a miniVNA > > > >> > http://www.miniradiosolutions.com/ > > > >> > > > > >> > This is a serial USB controlled instrument, and it has control > > software > > > >> > available for MS windows, and a very old and now non-working Linux > > > >> > application. > > > >> > > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > > control the > > > >> > miniVNA, obviously this application makes use of rxtx. > > > >> > > > > >> > The program worked fine on Windows, so I set about installing it > > onto > > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > > running > > > >> > fairly easily, sorting out the file locking by adding the uucp group > > to > > > >> > the users account as suggested (I used the 2.2pre binary files) I > > then > > > >> > passed the install instructions onto another miniVNA user, who also > > uses > > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > > >> > also having file lock problems, but the uucp fix did not work. > > Digging > > > >> > into his system I found that there have been some changes in SUSE > > 11.2. > > > >> > > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > > >> > > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > > >> > checked, so: > > > >> > > > > >> > SUSE 11.1, var/lock is root:uucp > > > >> > SUSE 11.2 var/lock is root:root > > > >> > > > > >> > A search on Google brought up several comments regarding this, and > > also > > > >> > a bugzilla entry. > > > >> > > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > >> > > > > >> > However from reading the various posts, some of which are in the > > bugzilla > > > >> > entry, it appears that many distros may be, or have changed to this > > > >> > configuration, and this will undoubtedly break several things, rxtx > > > >> > included. > > > >> > > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > > with the > > > >> > no lock file option during configure, and that solved his problem. > > > >> > > > > >> > As this issue will probably take some time to get resolved across > > all the > > > >> > various Linux distros, it might be worth considering changing the > > default > > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > > >> > versions of the lib in the binary archive. > > > >> > > > > >> > Thanks for your indulgence > > > >> > > > > >> > Andy > > > >> > > > > >> > _______________________________________________ > > > >> > Rxtx mailing list > > > >> > Rxtx at qbang.org > > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > > >> > > > > >> > > > >> > > > >> > > > >> -- > > > >> Atte: > > > >> Daniel Dario Morales Salas > > > >> Ingeniero Civil en Computaci?n e Inform?tica > > > >> Tel?fono: 02 684 3417 > > > >> Celular: 09 643 1802 > > > >> Santiago, Chile > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at qbang.org > > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > > > -- > > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > > > WWW: http://www.sharms.org/blog > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From Bob_Jacobsen at lbl.gov Thu Feb 4 09:26:49 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Thu, 4 Feb 2010 08:26:49 -0800 Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 Message-ID: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're using RXTX-2.2pre2, although it emits the known message about "Version mismatch". WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 After the usual messing around, we've got it working on 11 Windows versions, multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ have things working rarely say so, so I don't know whether anybody has gotten it to work on 10.4 or not. The problem encountered is this: dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib dyld: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib followed by the JVM crashing hard. I've got those dump files if that would help. Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If so, is there a patch I can get and build? Thanks Bob -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From tjarvi at qbang.org Thu Feb 4 14:22:21 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 4 Feb 2010 14:22:21 -0700 (MST) Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 In-Reply-To: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> References: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> Message-ID: On Thu, 4 Feb 2010, Bob Jacobsen wrote: > We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're > using RXTX-2.2pre2, although it emits the known message about "Version > mismatch". > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > > After the usual messing around, we've got it working on 11 Windows versions, > multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with > a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ > have things working rarely say so, so I don't know whether anybody has gotten > it to work on 10.4 or not. > > The problem encountered is this: > > dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > dyld: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > followed by the JVM crashing hard. I've got those dump files if that would > help. > > Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If > so, is there a patch I can get and build? > Hi Bob, I talked to a coworker about the problem you ran into. It appears that it is possible to target 'older' Mac systems through makefile configuration changes. "Configuring a Makefile-Based Project If you have a makefile-based project, you can also take advantage of SDK-based development, by adding the appropriate options to your compile and link commands. Using SDKs in makefile-based projects requires GCC 4.0 or later. To choose an SDK, you use the -isysroot option with the compiler and the -syslibroot option with the linker. Both options require that you specify the full path to the desired SDK directory. To set the Deployment OS version in a makefile, use a makefile variable of the form: ENVP= MACOSX_DEPLOYMENT_TARGET=10.4. To use this variable in your makefile, include it in front of your compile and link commands." http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html Or build on the oldest system you want to support. -- Trent Jarvi tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Thu Feb 4 14:56:19 2010 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Thu, 4 Feb 2010 14:56:19 -0700 Subject: [Rxtx] RXTX on 64 Bit Redhat In-Reply-To: References: <4ec9eab61001281448g3dd84910r867619948a4e0d7a@mail.gmail.com> Message-ID: Trent -- Finally fixed all my build related issues. I ran into another issue. On one of my machines my JDK is returning multiple folders for the "java.ext.dirs" (java.ext.dirs -> /opt/jdk1.6.0_17/jre/lib/ext:/usr/java/packages/lib/ext) system property. As a result my JVM wasn't able to detect the gnu.io.rxtx.properties. I am attaching a patch for RXTXCommDriver.java file to check for multiple locations. Also i have to assign permission 660 to all my dev ports to be located by RXTX. Pawan ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 5:12 PM To: Trent Jarvi Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Here is the error i get when i build the src from release-2-1-7 -bash-3.2$ make ( \ \ cd i686-pc-linux-gnu; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/ jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I/opt/jav a1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec - c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialImp.lo;\ if [ "Serial" = "Serial" ]; then \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I /opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_tim espec -c /home/jb_stg/rxtx/rxtx-devel/./src/fuserImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ else \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo; \ fi; \ ) gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/inclu de -I/opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need _timespec -c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -fPIC -DPIC -o /hom e/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/.libs/SerialImp.o /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:25:29: error: gnu_io_RXTXPort.h: No such file or directory In file included from /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:113: /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:91: error: expected specifier-qua lifier-list before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'jobject' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:408: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:409: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:410: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:411: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:415: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:416: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:417: error: expected '=', ',', '; ', 'asm' or '__attribute__' before 'is_interrupted' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:418: error: expected declaration specifiers or '...' before 'jint' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:424: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:441: error: expected ')' before ' *' token ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 4:57 PM To: Santosh Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Santosh -- Thank you. That fixed the issue. All -- What CVS branch or release should i use to get the latest RXTX src code. Pawan ________________________________ From: Santosh [mailto:santosh.ry at gmail.com] Sent: Thursday, January 28, 2010 3:49 PM To: Kharbanda, Pawan Cc: Trent Jarvi; rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat error "./configure: /bin/sh^M: bad interpreter: No such file or directory". I think you need to run dos2unix on script files before compiling. Thanks, Santosh On Thu, Jan 28, 2010 at 5:33 PM, Kharbanda, Pawan > wrote: Trent -- We are upgrading our exisiting OS and JDK on a project that rely heavily on RXTX api's. We are now using JDK1.6 32 bit (build 1.6.0_17-b04) and RedHat 5 on a 64 bit machine. Linux tocrhstg02.dot.state.co.us 2.6.18-164.6.1.el5 #1 SMP Tue Oct 27 11:30:06 EDT 2009 i686 i686 i386 GNU/Linux Red Hat Enterprise Linux Server release 5.4 (Tikanga) I tried to run version 2.1.7 r2 on it but not able to see any of my Digi ports I was able to access only /dev/ttyS0 (physical ports). Not sure if the problem is with the Digi driver or RXTX. I tried to open a Digi port with minicom and it worked fine. I also tried to get latest from CVS (rxtx-devel) and when I do "configure" I see this error "./configure: /bin/sh^M: bad interpreter: No such file or directory". Can someone please help me with this? Thanks for the help. Pawan _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch.txt URL: From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 01:02:21 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 13:32:21 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> My serial port driver(apparently) does not support receive timeout.I registered an event listener for DATA_AVAILABLE. However, the control never seems to come out of the 'while' loop.Shouldn't the InputStream.read return a '-1' immediately if no data is available (this seems to be the default operation)? This was tried on a x86 Linux desktop using rxtx-2.1-7 I've added the snippet for clarity: /******************************************************************************************************************************************************************************/ mySerialPort.enableReceiveThreshold(2000);//Trying to set a time limit for read calls System.out.println(mySerialPort.isReceiveTimeoutEnabled()); // I get FALSE, so its not supported on hardware. mySerialPort.addEventListener(this); mySerialPort.notifyOnDataAvailable(true);//register a event with //my SerialEvent listener implementation: public void serialEvent(SerialPortEvent arg0) { int newData=0; switch(arg0.getEventType()){ case SerialPortEvent.DATA_AVAILABLE: while (newData != -1) { try { newData = is.read();//This should eventually return a -1 if no data is available within a timeout.PROBLEM!! System.out.println("Got a byte from port:"+newData); if (newData == -1) { break; } } catch (IOException ex) { System.err.println(ex); return; } } break; } return; } /******************************************************************************************************************************************************************************/ Thanks and regards, Ravi From michael.erskine at ketech.com Wed Feb 3 02:26:50 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 09:26:50 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From michael.erskine at ketech.com Wed Feb 3 05:03:30 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 12:03:30 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > Michael Erskine > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > > Your event handler should handle the event and return immediately so that its > controlling thread can handle other events. I recommend a single read in the > following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) > reads all available bytes up to the size of the buffer returning the number of > bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } After posting this I considered the glaring possibility of the rawbuf read buffer being too small to receive all the available bytes and perhaps skipping data: after all, I'm guessing that is why we see so many posts asking for help with blocking implementations of read event handlers looping on "while(bytes are available)". I've spent this morning writing an extensive multi-threaded unit test suite that includes tests with a tiny buffer compared to the amount of data available and found that no data was being skipped. I now want to know why! The SerialPortEvent.DATA_AVAILABLE event must be being fired again if there is more data available on the input stream. If that is the case then it should be heavily documented with good examples in the wiki to avoid the types of developer anguish we see so regularly. BTW: I'm not at liberty to post the JUnit tests as they use my company's unit test suite framework. Regards, Michael Erskine. From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 06:18:04 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 18:48:04 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Hello Michael, I tried out your suggestion but the problem is that the read(rawbuf) blocks until the entire length of the rawbuf array has been read (blocking). I cannot decide on a reasonable size of the array because it varies from 2 bytes to as much as 50 byes (i'm communicating with a modem,each response is of a different length), which is why i wanted to use non blocking calls. But on a side note, read(byte[]) in turn calls the read() in a loop.In the native C function, the read is supposed to return a -1 upon timeout.But my driver does not support timeout.The default timeout value is zero and the linux select call upon zero time out causes an infinite wait.What am i missing...... Thanks and regards, Ravi Date: Wed, 3 Feb 2010 09:26:50 +0000 From: Michael Erskine To: "rxtx at qbang.org" Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: Content-Type: text/plain; charset="us-ascii" > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From m.kirkland at comcast.net Wed Feb 3 06:46:03 2010 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 3 Feb 2010 05:46:03 -0800 Subject: [Rxtx] One port blocking another port In-Reply-To: References: Message-ID: <68768633814F4D7D86761D34F0764FE0@bengal.net> It turns out this is caused by having the RTS/CTS flow control turned on and me not providing a true on the RTS pin. Somehow it seems the port timing out on a read allows the write to proceed. This is not an issue for my application but I wonder if the write should not proceed until the RTS pin is true even if a read times out. mk -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Monday, January 25, 2010 7:48 PM To: Mike Kirkland Cc: rxtx at qbang.org Subject: Re: [Rxtx] One port blocking another port On Mon, 25 Jan 2010, Mike Kirkland wrote: > > Hi All, > > ? > > I have a program that reads from one com port and writes to another com > port. It also does the same thing in reverse (reads from the second com port > and writes to the first one. It basically ties two com ports together. > > ? > > One port is very chatty and has a consent stream of data. The other port has > very little data. > > ? > > Both ports use a 5000 ms (5 second) time out. > > ? > > The issue I am having is that is appears that the first port?s write to the > second port is blocked while the second port is waiting for input. The first > port?s write proceeds only after the second port has timed out. > > ? > > I suppose I could have something twisted around in my code but I was > wondering if this is a know issue? > Hi Kirk, I've not seen a report like this. Perhaps some simple reproduction code will reveal a problem on your end or help us identify a problem in rxtx. I think there are several users doing multiport communication. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Wed Feb 3 07:03:58 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:03:58 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Message-ID: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> 2010/2/3 Ravishankar N > Hello Michael, > [..] > But on a side note, read(byte[]) in turn calls the read() in a loop.In the > native C function, the read is supposed to return a -1 upon timeout.But my > driver > does not support timeout.The default timeout value is zero and the linux > select call upon zero time out causes an infinite wait.What am i > missing...... > > When I have tested RXTX between platforms, I have observed "hangup" inside JNI driver when no data in Linux, is normal thing. Solution was setting the timeout for RXTX when no data from JNI driver. Something like that: commPort.enableReceiveTimeout(10); And it works perfect.... The only difference is that I am NOT using events - I am using continous read in separate thread and if data is available, is parsed and transferred to application using exception. Regards Mariusz > Thanks and regards, > Ravi > > Date: Wed, 3 Feb 2010 09:26:50 +0000 > From: Michael Erskine > To: "rxtx at qbang.org" > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > Message-ID: > > > Content-Type: text/plain; charset="us-ascii" > > > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of > > Ravishankar N > > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > > > My serial port driver(apparently) does not support receive timeout.I > > registered an event listener for DATA_AVAILABLE. However, the control > never > > seems to come out of the 'while' loop.Shouldn't the > > InputStream.read return a '-1' immediately if no data is available (this > seems > > to be the default operation)? > > Your event handler should handle the event and return immediately so that > its controlling thread can handle other events. I recommend a single read in > the following manner: rawbuf is a byte[] of "reasonable" size and the > read(byte[]) reads all available bytes up to the size of the buffer > returning the number of bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } > > This style of reading has worked for me with RXTX on Linux and Windows XP > for a good few years now in railway industry communications systems. Any > timeouts (largely unnecessary in my applications) can be handled elsewhere, > usually at a higher layer. > > Regards, > Michael Erskine. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Feb 3 07:22:55 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 3 Feb 2010 09:22:55 -0500 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: I'm guessing that this is driver specific. I recently had to support a select()/poll() infrastructure for a linux serial DD, its certainly non trivial to support async IO, so I suspect the problem in this case has to do with missing poll infrastructure in the device driver. This also has to coupled with special open flags for the device (which is within the rxtx code) The key routines within a 2.6 kernel linux device driver are shown below (if you have access to it for your particular device) are indicated below (here is a snippet from my device driver c code that supports polling/select). User space code to test this shown below also, note that the device needs to be opened with the O_NONBLOCK option to support the select/poll api // device driver code ..... /* * File operations supported by this driver. */ static struct file_operations iop_fops = { .owner = THIS_MODULE, .check_flags= iop_check_flags, .ioctl = iop_ioctl, .open = iop_open, .poll = iop_poll, // SUPPORT FOR SELECT/POLL infrastructure .read = iop_read, .release = iop_release, .write = iop_write, }; /** * Select/poll/epoll infrastructure. * * @param file * @param wait * * @return */ static unsigned int iop_poll(struct file *filp, poll_table *wait) { struct iop_device *devp = (struct iop_device *)filp->private_data; // the poll_table wait arg is an opaque pointer poll_wait(filp, &devp->readq, wait); // return from poll indicating whether we have read/write data unsigned int mask = 0; if (kfifo_len(devp->rx_fifo)) { mask |= (POLLIN | POLLRDNORM); } // @JC We don't do select on write yet // if (kfifo_len(devp->tx_fifo)) { // mask |= (POLLOUT | POLLWRNORM); // } // Only print out while debugging // if (mask != 0) { // printk (KERN_INFO "%s: [%04x]\n", __FUNCTION__, mask); // } return mask; } /** * device driver blocking and non blocking read function. This * function reads the requested number of bytes from the read * kfifo blocking as required. * * @param filp * @param buf * @param count * @param f_pos * * @return */ static ssize_t iop_read(struct file *filp, char __user *buf, size_t count, loff_t * ppos) { // access appropriate device struct struct iop_device *devp = (struct iop_device *) filp->private_data; ssize_t retval; // support non blocking mode (default) by checking if the kfifo is empty first if ((kfifo_len(devp->rx_fifo)==0) && (filp->f_flags & O_NONBLOCK)) { return -EAGAIN; } // wait for rx_fifo to receive data via receive interrupts retval = wait_event_interruptible(devp->readq, kfifo_len(devp->rx_fifo) != 0); // check for some error condition if (retval) { printk (KERN_ERR "%s: wait_event_interruptible returned[%d]\n", __FUNCTION__, retval); return retval; } // copy max requested bytes from rx_fifo to device buffer // this may still leave bytes in the kfifo for a subsequent read // if we are reading in a loop retval = kfifo_get(devp->rx_fifo, devp->rxbuf, count); // printk (KERN_INFO "%s: [%d] byte(s)\n", __FUNCTION__, retval); if (copy_to_user(buf, devp->rxbuf, retval)) { printk (KERN_ERR "%s: problem copying rx_fifo data to user buffer\n", __FUNCTION__); return -EFAULT; } return retval; } // a selection of my user space code reading via select()/poll()..... // user space open code iop_fd = ::open( deviceName.data(), O_RDWR | O_NONBLOCK); while ((bytes_to_expect - bytes_read) > 0) { // must reinitialize these between select calls fd_set readfds; FD_ZERO( &readfds ); FD_SET( iop_fd, &readfds ); // 1s sec read polling timeout struct timeval timeout; timeout.tv_sec = 1; timeout.tv_usec = 0; int rc = select( FD_SETSIZE, &readfds, NULL, NULL, &timeout ); // read from file when descriptor // indicates data available without blocking if ((rc > 0) && FD_ISSET(iop_fd, &readfds)) { // read into the appropriate offset within the rx_buf int temp = read(iop_fd, rx_buf + bytes_read, bytes_to_expect - bytes_read); if (!temp) { printf("EOF detected with %d bytes expected\n", bytes_to_expect - bytes_read); } else { bytes_read += temp; } } else if (rc < 0){ printf("%s: select on [%s], bytes_read[%d], errno=%d\n", __FUNCTION__, thread_args->device, bytes_read, errno); } else { printf("%s: select on [%s], bytes_read[%d], timeout\n", __FUNCTION__, thread_args->device, bytes_read); } } On Wed, Feb 3, 2010 at 9:03 AM, Mariusz Dec wrote: > > > 2010/2/3 Ravishankar N > >> Hello Michael, >> [..] >> >> But on a side note, read(byte[]) in turn calls the read() in a loop.In the >> native C function, the read is supposed to return a -1 upon timeout.But my >> driver >> does not support timeout.The default timeout value is zero and the linux >> select call upon zero time out causes an infinite wait.What am i >> missing...... >> >> > When I have tested RXTX between platforms, I have observed "hangup" inside > JNI driver when no data in Linux, is normal thing. > > Solution was setting the timeout for RXTX when no data from JNI driver. > > Something like that: > > commPort.enableReceiveTimeout(10); > > And it works perfect.... > > The only difference is that I am NOT using events - I am using continous > read in separate thread and if data is available, is parsed and transferred > to application using exception. > > Regards > Mariusz > > > >> Thanks and regards, >> Ravi >> >> Date: Wed, 3 Feb 2010 09:26:50 +0000 >> From: Michael Erskine >> To: "rxtx at qbang.org" >> Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? >> Message-ID: >> >> >> Content-Type: text/plain; charset="us-ascii" >> >> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >> Of >> > Ravishankar N >> > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? >> > >> > My serial port driver(apparently) does not support receive timeout.I >> > registered an event listener for DATA_AVAILABLE. However, the control >> never >> > seems to come out of the 'while' loop.Shouldn't the >> > InputStream.read return a '-1' immediately if no data is available (this >> seems >> > to be the default operation)? >> >> Your event handler should handle the event and return immediately so that >> its controlling thread can handle other events. I recommend a single read in >> the following manner: rawbuf is a byte[] of "reasonable" size and the >> read(byte[]) reads all available bytes up to the size of the buffer >> returning the number of bytes actually read... >> >> case SerialPortEvent.DATA_AVAILABLE: >> try { >> int i = is.read(rawbuf); >> if (i == -1) { >> << process EOF condition - should never happen >> >> return; >> } >> << process bytes (rawbuf, i); >> >> return; >> } catch (IOException e) { >> << promptly deal with exception >> >> return; >> } >> >> This style of reading has worked for me with RXTX on Linux and Windows XP >> for a good few years now in railway industry communications systems. Any >> timeouts (largely unnecessary in my applications) can be handled elsewhere, >> usually at a higher layer. >> >> Regards, >> Michael Erskine. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Feb 3 07:33:27 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:33:27 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: <73a89f361002030633j682610afia48dc7accd8e049b@mail.gmail.com> 2010/2/3 John Coffey > I'm guessing that this is driver specific. I recently had to support a > select()/poll() infrastructure for a linux serial DD, its certainly non > trivial to support async IO, so I suspect the problem in this case has to do > with missing poll infrastructure in the device driver. This also has to > coupled with special open flags for the device (which is within the rxtx > code) > > Yes, you are right, it may be driver specific, but in my case I haven't changed blocking JNI driver. I have added ONLY one call to RXTX method mentioned in my previous post and blocking (as seen as from Java app) gone out... Maybe this is not elegant, but works without problem in my app. I am using only FTDI chips and their drivers from couple of years and maybe this is the kind of the way to have no many problems with serial as well? Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From andyrxtx at g0poy.co.uk Wed Feb 3 11:09:04 2010 From: andyrxtx at g0poy.co.uk (andyrxtx at g0poy.co.uk) Date: Wed, 3 Feb 2010 18:09:04 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes Message-ID: <20100203180904.164f24dd@workstation.site> ?Hello RXTX group, I have just joined this group, and this is my first posting. I wanted to pass on some information regarding rxtx, so apologies if this has been brought up before. I have searched back through the archives but nothing specific came up. I am not a Java programmer, and I only came across rxtx a few days ago. I use a piece of test equipment called a miniVNA http://www.miniradiosolutions.com/ This is a serial USB controlled instrument, and it has control software available for MS windows, and a very old and now non-working Linux application. A few days ago Dietmar, DL2SBA released a Java application to control the miniVNA, obviously this application makes use of rxtx. The program worked fine on Windows, so I set about installing it onto Linux. I use SUSE11.1 After a few false starts, I got the system running fairly easily, sorting out the file locking by adding the uucp group to the users account as suggested (I used the 2.2pre binary files) I then passed the install instructions onto another miniVNA user, who also uses SUSE, but he ran into problems. To cut a long story short, he was also having file lock problems, but the uucp fix did not work. Digging into his system I found that there have been some changes in SUSE 11.2. tty ports are now assigned to the dialout group rather than uucp. A hint in the rxtx INSTALL file, suggested that var/lock needs to be checked, so: SUSE 11.1, var/lock is root:uucp SUSE 11.2 var/lock is root:root A search on Google brought up several comments regarding this, and also a bugzilla entry. https://bugzilla.novell.com/show_bug.cgi?id=552095 However from reading the various posts, some of which are in the bugzilla entry, it appears that many distros may be, or have changed to this configuration, and this will undoubtedly break several things, rxtx included. I solved my fellow SUSE users problem by compiling the rxtx libs with the no lock file option during configure, and that solved his problem. As this issue will probably take some time to get resolved across all the various Linux distros, it might be worth considering changing the default on the Linux build of rxtx not to use lockfiles, or provide the two versions of the lib in the binary archive. Thanks for your indulgence Andy From damorales at gmail.com Wed Feb 3 11:33:23 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 15:33:23 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203180904.164f24dd@workstation.site> References: <20100203180904.164f24dd@workstation.site> Message-ID: Hi I had the same problem in Mandriva 2010 and yes, adding the user to the uucp group did not work as it used to be in earlier versions of linux distros, causing RXTX to not work as non root user. The problem appears because the existense of UDEV, now you MUST add a RULE so the group (uucp or whatever) have access (Read, Write, Execute) to the Serial Port. To solve the problem, without needing to recompile RXTX, you must add a rule to grant permissions (0666) to the group for the device or port (tty*, ttyUSB*, etc). I do not remember now what is the line i added but when i come back home i will give it to you (i am at work now). Greetings ! 2010/2/3 > Hello RXTX group, > > I have just joined this group, and this is my first posting. > I wanted to pass on some information regarding rxtx, so apologies if > this has been brought up before. I have searched back through the > archives but nothing specific came up. > > I am not a Java programmer, and I only came across rxtx a few days ago. > > I use a piece of test equipment called a miniVNA > http://www.miniradiosolutions.com/ > > This is a serial USB controlled instrument, and it has control software > available for MS windows, and a very old and now non-working Linux > application. > > A few days ago Dietmar, DL2SBA released a Java application to control the > miniVNA, obviously this application makes use of rxtx. > > The program worked fine on Windows, so I set about installing it onto > Linux. I use SUSE11.1 After a few false starts, I got the system running > fairly easily, sorting out the file locking by adding the uucp group to > the users account as suggested (I used the 2.2pre binary files) I then > passed the install instructions onto another miniVNA user, who also uses > SUSE, but he ran into problems. To cut a long story short, he was > also having file lock problems, but the uucp fix did not work. Digging > into his system I found that there have been some changes in SUSE 11.2. > > tty ports are now assigned to the dialout group rather than uucp. > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > checked, so: > > SUSE 11.1, var/lock is root:uucp > SUSE 11.2 var/lock is root:root > > A search on Google brought up several comments regarding this, and also > a bugzilla entry. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > However from reading the various posts, some of which are in the bugzilla > entry, it appears that many distros may be, or have changed to this > configuration, and this will undoubtedly break several things, rxtx > included. > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > no lock file option during configure, and that solved his problem. > > As this issue will probably take some time to get resolved across all the > various Linux distros, it might be worth considering changing the default > on the Linux build of rxtx not to use lockfiles, or provide the two > versions of the lib in the binary archive. > > Thanks for your indulgence > > Andy > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Wed Feb 3 12:07:02 2010 From: andy at g0poy.com (Andy Eskelson) Date: Wed, 3 Feb 2010 19:07:02 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> Message-ID: <20100203190702.1b0e7015@workstation.site> Thanks Daniel, I am aware of the permissions problem, I have had a udev rules to solve this for other programs for some time. . I don't think that this is the same problem. as far as I can understand things, the lock files are written in var/lock. Previously var/lock and dev/tty-whatever were the same group. Now with var/lock owned by and with a group of root:root anything other than root cannot create a lock file. Even minicom is broken by this change. This change is going to have quite a few knock-on effects I think. Andy On Wed, 3 Feb 2010 15:33:23 -0300 Daniel Morales Salas wrote: > Hi > > I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > group did not work as it used to be in earlier versions of linux distros, > causing RXTX to not work as non root user. > > The problem appears because the existense of UDEV, now you MUST add a RULE > so the group (uucp or whatever) have access (Read, Write, Execute) to the > Serial Port. > > To solve the problem, without needing to recompile RXTX, you must add a rule > to grant permissions (0666) to the group for the device or port (tty*, > ttyUSB*, etc). I do not remember now what is the line i added but when i > come back home i will give it to you (i am at work now). > > Greetings ! > > 2010/2/3 > > > Hello RXTX group, > > > > I have just joined this group, and this is my first posting. > > I wanted to pass on some information regarding rxtx, so apologies if > > this has been brought up before. I have searched back through the > > archives but nothing specific came up. > > > > I am not a Java programmer, and I only came across rxtx a few days ago. > > > > I use a piece of test equipment called a miniVNA > > http://www.miniradiosolutions.com/ > > > > This is a serial USB controlled instrument, and it has control software > > available for MS windows, and a very old and now non-working Linux > > application. > > > > A few days ago Dietmar, DL2SBA released a Java application to control the > > miniVNA, obviously this application makes use of rxtx. > > > > The program worked fine on Windows, so I set about installing it onto > > Linux. I use SUSE11.1 After a few false starts, I got the system running > > fairly easily, sorting out the file locking by adding the uucp group to > > the users account as suggested (I used the 2.2pre binary files) I then > > passed the install instructions onto another miniVNA user, who also uses > > SUSE, but he ran into problems. To cut a long story short, he was > > also having file lock problems, but the uucp fix did not work. Digging > > into his system I found that there have been some changes in SUSE 11.2. > > > > tty ports are now assigned to the dialout group rather than uucp. > > > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > checked, so: > > > > SUSE 11.1, var/lock is root:uucp > > SUSE 11.2 var/lock is root:root > > > > A search on Google brought up several comments regarding this, and also > > a bugzilla entry. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > However from reading the various posts, some of which are in the bugzilla > > entry, it appears that many distros may be, or have changed to this > > configuration, and this will undoubtedly break several things, rxtx > > included. > > > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > > no lock file option during configure, and that solved his problem. > > > > As this issue will probably take some time to get resolved across all the > > various Linux distros, it might be worth considering changing the default > > on the Linux build of rxtx not to use lockfiles, or provide the two > > versions of the lib in the binary archive. > > > > Thanks for your indulgence > > > > Andy > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From thisdyingdream at gmail.com Wed Feb 3 12:32:35 2010 From: thisdyingdream at gmail.com (Steven Harms) Date: Wed, 3 Feb 2010 14:32:35 -0500 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203190702.1b0e7015@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: This is currently a bug in OpenSUSE that affects more than just rxtx, and is a result of unified udev rules. You can work around this by making udev change the group back to uucp until something more happens. https://bugzilla.novell.com/show_bug.cgi?id=552095 Thanks, Steve On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > Thanks Daniel, > > I am aware of the permissions problem, I have had a udev rules to solve > this for other programs for some time. > . > I don't think that this is the same problem. as far as I can understand > things, the lock files are written in var/lock. Previously var/lock and > dev/tty-whatever were the same group. Now with var/lock owned by and with > a group of root:root anything other than root cannot create a lock > file. Even minicom is broken by this change. > > This change is going to have quite a few knock-on effects I think. > > > Andy > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > Daniel Morales Salas wrote: > >> Hi >> >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp >> group did not work as it used to be in earlier versions of linux distros, >> causing RXTX to not work as non root user. >> >> The problem appears because the existense of UDEV, now you MUST add a RULE >> so the group (uucp or whatever) have access (Read, Write, Execute) to the >> Serial Port. >> >> To solve the problem, without needing to recompile RXTX, you must add a rule >> to grant permissions (0666) to the group for the device or port (tty*, >> ttyUSB*, etc). I do not remember now what is the line i added but when i >> come back home i will give it to you (i am at work now). >> >> Greetings ! >> >> 2010/2/3 >> >> > Hello RXTX group, >> > >> > I have just joined this group, and this is my first posting. >> > I wanted to pass on ?some information regarding rxtx, so apologies if >> > this has been brought up before. I have searched back through the >> > archives but nothing specific came up. >> > >> > I am not a Java programmer, and I only came across rxtx a few days ago. >> > >> > I use a piece of test equipment called a miniVNA >> > http://www.miniradiosolutions.com/ >> > >> > This is a serial USB controlled instrument, and it has control software >> > available for MS windows, and a very old and now non-working Linux >> > application. >> > >> > A few days ago Dietmar, DL2SBA released a Java application to control the >> > miniVNA, obviously this application makes use of rxtx. >> > >> > The program worked fine on Windows, so I set about installing it onto >> > Linux. I use SUSE11.1 After a few false starts, I got the system running >> > fairly easily, sorting out the file locking by adding the uucp group to >> > the users account as suggested (I used the 2.2pre binary files) I then >> > passed the install instructions onto another miniVNA user, who also uses >> > SUSE, but he ran into problems. To cut a long story short, he was >> > also having file lock problems, but the uucp fix did not work. Digging >> > into his system I found that there have been some changes in SUSE 11.2. >> > >> > tty ports are now assigned to the dialout group rather than uucp. >> > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be >> > checked, so: >> > >> > SUSE 11.1, var/lock is root:uucp >> > SUSE 11.2 var/lock is root:root >> > >> > A search on Google brought up several comments regarding this, and also >> > a ?bugzilla entry. >> > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 >> > >> > However from reading the various posts, some of which are in the bugzilla >> > entry, it appears that many distros may be, or have changed to this >> > configuration, and this will undoubtedly break several things, rxtx >> > included. >> > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the >> > no lock file option during configure, and that solved his problem. >> > >> > As this issue will probably take some time to get resolved across all the >> > various Linux distros, it might be worth considering changing the default >> > on the Linux build of rxtx not to use lockfiles, or provide the two >> > versions of the lib in the binary archive. >> > >> > Thanks for your indulgence >> > >> > Andy >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> >> >> >> -- >> Atte: >> Daniel Dario Morales Salas >> Ingeniero Civil en Computaci?n e Inform?tica >> Tel?fono: 02 684 3417 >> Celular: 09 643 1802 >> Santiago, Chile > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 WWW: http://www.sharms.org/blog From andy at g0poy.com Wed Feb 3 17:58:29 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 00:58:29 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: <20100204005829.7dc944e1@workstation.site> Thanks Steve, changing the serial ports back the uucp is not a big problem. I have a udev rule that can be easily modified already. However I cannot see any way of dealing with the var/lock problem apart from making it writable to all. Any thoughts? Andy On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms wrote: > This is currently a bug in OpenSUSE that affects more than just rxtx, > and is a result of unified udev rules. You can work around this by > making udev change the group back to uucp until something more > happens. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > Thanks, > > Steve > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > Thanks Daniel, > > > > I am aware of the permissions problem, I have had a udev rules to solve > > this for other programs for some time. > > . > > I don't think that this is the same problem. as far as I can understand > > things, the lock files are written in var/lock. Previously var/lock and > > dev/tty-whatever were the same group. Now with var/lock owned by and with > > a group of root:root anything other than root cannot create a lock > > file. Even minicom is broken by this change. > > > > This change is going to have quite a few knock-on effects I think. > > > > > > Andy > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > Daniel Morales Salas wrote: > > > >> Hi > >> > >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > >> group did not work as it used to be in earlier versions of linux distros, > >> causing RXTX to not work as non root user. > >> > >> The problem appears because the existense of UDEV, now you MUST add a RULE > >> so the group (uucp or whatever) have access (Read, Write, Execute) to the > >> Serial Port. > >> > >> To solve the problem, without needing to recompile RXTX, you must add a rule > >> to grant permissions (0666) to the group for the device or port (tty*, > >> ttyUSB*, etc). I do not remember now what is the line i added but when i > >> come back home i will give it to you (i am at work now). > >> > >> Greetings ! > >> > >> 2010/2/3 > >> > >> > Hello RXTX group, > >> > > >> > I have just joined this group, and this is my first posting. > >> > I wanted to pass on ?some information regarding rxtx, so apologies if > >> > this has been brought up before. I have searched back through the > >> > archives but nothing specific came up. > >> > > >> > I am not a Java programmer, and I only came across rxtx a few days ago. > >> > > >> > I use a piece of test equipment called a miniVNA > >> > http://www.miniradiosolutions.com/ > >> > > >> > This is a serial USB controlled instrument, and it has control software > >> > available for MS windows, and a very old and now non-working Linux > >> > application. > >> > > >> > A few days ago Dietmar, DL2SBA released a Java application to control the > >> > miniVNA, obviously this application makes use of rxtx. > >> > > >> > The program worked fine on Windows, so I set about installing it onto > >> > Linux. I use SUSE11.1 After a few false starts, I got the system running > >> > fairly easily, sorting out the file locking by adding the uucp group to > >> > the users account as suggested (I used the 2.2pre binary files) I then > >> > passed the install instructions onto another miniVNA user, who also uses > >> > SUSE, but he ran into problems. To cut a long story short, he was > >> > also having file lock problems, but the uucp fix did not work. Digging > >> > into his system I found that there have been some changes in SUSE 11.2. > >> > > >> > tty ports are now assigned to the dialout group rather than uucp. > >> > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > >> > checked, so: > >> > > >> > SUSE 11.1, var/lock is root:uucp > >> > SUSE 11.2 var/lock is root:root > >> > > >> > A search on Google brought up several comments regarding this, and also > >> > a ?bugzilla entry. > >> > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > >> > > >> > However from reading the various posts, some of which are in the bugzilla > >> > entry, it appears that many distros may be, or have changed to this > >> > configuration, and this will undoubtedly break several things, rxtx > >> > included. > >> > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the > >> > no lock file option during configure, and that solved his problem. > >> > > >> > As this issue will probably take some time to get resolved across all the > >> > various Linux distros, it might be worth considering changing the default > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > >> > versions of the lib in the binary archive. > >> > > >> > Thanks for your indulgence > >> > > >> > Andy > >> > > >> > _______________________________________________ > >> > Rxtx mailing list > >> > Rxtx at qbang.org > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > >> > >> > >> > >> -- > >> Atte: > >> Daniel Dario Morales Salas > >> Ingeniero Civil en Computaci?n e Inform?tica > >> Tel?fono: 02 684 3417 > >> Celular: 09 643 1802 > >> Santiago, Chile > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > WWW: http://www.sharms.org/blog From damorales at gmail.com Wed Feb 3 18:26:38 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 22:26:38 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100204005829.7dc944e1@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: Hello I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva 2010 this is what i get: drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ and i don't have ANY problem with lock files and RXTX in my java software. All i had to do was add this rule to udev: # serial KERNEL=="tty*", GROUP="uucp", MODE="0666" and that was all. Of course my user (metalklesk) is part of uucp group. I did not make /var/lock writable to all users. Greetings ! 2010/2/3 Andy Eskelson > Thanks Steve, > > changing the serial ports back the uucp is not a big problem. I have a > udev rule that can be easily modified already. However I cannot see any > way of dealing with the var/lock problem apart from making it writable to > all. Any thoughts? > > Andy > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > wrote: > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > and is a result of unified udev rules. You can work around this by > > making udev change the group back to uucp until something more > > happens. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > Thanks, > > > > Steve > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > Thanks Daniel, > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > this for other programs for some time. > > > . > > > I don't think that this is the same problem. as far as I can understand > > > things, the lock files are written in var/lock. Previously var/lock and > > > dev/tty-whatever were the same group. Now with var/lock owned by and > with > > > a group of root:root anything other than root cannot create a lock > > > file. Even minicom is broken by this change. > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > Daniel Morales Salas wrote: > > > > > >> Hi > > >> > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > the uucp > > >> group did not work as it used to be in earlier versions of linux > distros, > > >> causing RXTX to not work as non root user. > > >> > > >> The problem appears because the existense of UDEV, now you MUST add a > RULE > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > the > > >> Serial Port. > > >> > > >> To solve the problem, without needing to recompile RXTX, you must add > a rule > > >> to grant permissions (0666) to the group for the device or port (tty*, > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > i > > >> come back home i will give it to you (i am at work now). > > >> > > >> Greetings ! > > >> > > >> 2010/2/3 > > >> > > >> > Hello RXTX group, > > >> > > > >> > I have just joined this group, and this is my first posting. > > >> > I wanted to pass on some information regarding rxtx, so apologies > if > > >> > this has been brought up before. I have searched back through the > > >> > archives but nothing specific came up. > > >> > > > >> > I am not a Java programmer, and I only came across rxtx a few days > ago. > > >> > > > >> > I use a piece of test equipment called a miniVNA > > >> > http://www.miniradiosolutions.com/ > > >> > > > >> > This is a serial USB controlled instrument, and it has control > software > > >> > available for MS windows, and a very old and now non-working Linux > > >> > application. > > >> > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > control the > > >> > miniVNA, obviously this application makes use of rxtx. > > >> > > > >> > The program worked fine on Windows, so I set about installing it > onto > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > running > > >> > fairly easily, sorting out the file locking by adding the uucp group > to > > >> > the users account as suggested (I used the 2.2pre binary files) I > then > > >> > passed the install instructions onto another miniVNA user, who also > uses > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > >> > also having file lock problems, but the uucp fix did not work. > Digging > > >> > into his system I found that there have been some changes in SUSE > 11.2. > > >> > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > >> > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > >> > checked, so: > > >> > > > >> > SUSE 11.1, var/lock is root:uucp > > >> > SUSE 11.2 var/lock is root:root > > >> > > > >> > A search on Google brought up several comments regarding this, and > also > > >> > a bugzilla entry. > > >> > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > >> > > > >> > However from reading the various posts, some of which are in the > bugzilla > > >> > entry, it appears that many distros may be, or have changed to this > > >> > configuration, and this will undoubtedly break several things, rxtx > > >> > included. > > >> > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > with the > > >> > no lock file option during configure, and that solved his problem. > > >> > > > >> > As this issue will probably take some time to get resolved across > all the > > >> > various Linux distros, it might be worth considering changing the > default > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > >> > versions of the lib in the binary archive. > > >> > > > >> > Thanks for your indulgence > > >> > > > >> > Andy > > >> > > > >> > _______________________________________________ > > >> > Rxtx mailing list > > >> > Rxtx at qbang.org > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > >> > > > >> > > >> > > >> > > >> -- > > >> Atte: > > >> Daniel Dario Morales Salas > > >> Ingeniero Civil en Computaci?n e Inform?tica > > >> Tel?fono: 02 684 3417 > > >> Celular: 09 643 1802 > > >> Santiago, Chile > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at qbang.org > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > -- > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > WWW: http://www.sharms.org/blog > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Thu Feb 4 05:31:46 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 12:31:46 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: <20100204123146.6cffeb67@workstation.site> Thank's for the confirmation. Something odd is going on somewhere in SUSE 11.2. I'll have to build up a local SUSE11.2 system to see if I can nail down exactly what is going on. Something is blocking the lockfiles in var/lock. The net is nice, but it's a bit difficult trying to work out what is going on what the machine in question is in Germany and I'm in the UK :-) Andy On Wed, 3 Feb 2010 22:26:38 -0300 Daniel Morales Salas wrote: > Hello > > I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva > 2010 this is what i get: > > drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ > > and i don't have ANY problem with lock files and RXTX in my java software. > All i had to do was add this rule to udev: > > # serial > KERNEL=="tty*", GROUP="uucp", MODE="0666" > > and that was all. Of course my user (metalklesk) is part of uucp group. > I did not make /var/lock writable to all users. > > Greetings ! > > 2010/2/3 Andy Eskelson > > > Thanks Steve, > > > > changing the serial ports back the uucp is not a big problem. I have a > > udev rule that can be easily modified already. However I cannot see any > > way of dealing with the var/lock problem apart from making it writable to > > all. Any thoughts? > > > > Andy > > > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > > wrote: > > > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > > and is a result of unified udev rules. You can work around this by > > > making udev change the group back to uucp until something more > > > happens. > > > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > > > Thanks, > > > > > > Steve > > > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > > Thanks Daniel, > > > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > > this for other programs for some time. > > > > . > > > > I don't think that this is the same problem. as far as I can understand > > > > things, the lock files are written in var/lock. Previously var/lock and > > > > dev/tty-whatever were the same group. Now with var/lock owned by and > > with > > > > a group of root:root anything other than root cannot create a lock > > > > file. Even minicom is broken by this change. > > > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > > Daniel Morales Salas wrote: > > > > > > > >> Hi > > > >> > > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > > the uucp > > > >> group did not work as it used to be in earlier versions of linux > > distros, > > > >> causing RXTX to not work as non root user. > > > >> > > > >> The problem appears because the existense of UDEV, now you MUST add a > > RULE > > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > > the > > > >> Serial Port. > > > >> > > > >> To solve the problem, without needing to recompile RXTX, you must add > > a rule > > > >> to grant permissions (0666) to the group for the device or port (tty*, > > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > > i > > > >> come back home i will give it to you (i am at work now). > > > >> > > > >> Greetings ! > > > >> > > > >> 2010/2/3 > > > >> > > > >> > Hello RXTX group, > > > >> > > > > >> > I have just joined this group, and this is my first posting. > > > >> > I wanted to pass on some information regarding rxtx, so apologies > > if > > > >> > this has been brought up before. I have searched back through the > > > >> > archives but nothing specific came up. > > > >> > > > > >> > I am not a Java programmer, and I only came across rxtx a few days > > ago. > > > >> > > > > >> > I use a piece of test equipment called a miniVNA > > > >> > http://www.miniradiosolutions.com/ > > > >> > > > > >> > This is a serial USB controlled instrument, and it has control > > software > > > >> > available for MS windows, and a very old and now non-working Linux > > > >> > application. > > > >> > > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > > control the > > > >> > miniVNA, obviously this application makes use of rxtx. > > > >> > > > > >> > The program worked fine on Windows, so I set about installing it > > onto > > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > > running > > > >> > fairly easily, sorting out the file locking by adding the uucp group > > to > > > >> > the users account as suggested (I used the 2.2pre binary files) I > > then > > > >> > passed the install instructions onto another miniVNA user, who also > > uses > > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > > >> > also having file lock problems, but the uucp fix did not work. > > Digging > > > >> > into his system I found that there have been some changes in SUSE > > 11.2. > > > >> > > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > > >> > > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > > >> > checked, so: > > > >> > > > > >> > SUSE 11.1, var/lock is root:uucp > > > >> > SUSE 11.2 var/lock is root:root > > > >> > > > > >> > A search on Google brought up several comments regarding this, and > > also > > > >> > a bugzilla entry. > > > >> > > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > >> > > > > >> > However from reading the various posts, some of which are in the > > bugzilla > > > >> > entry, it appears that many distros may be, or have changed to this > > > >> > configuration, and this will undoubtedly break several things, rxtx > > > >> > included. > > > >> > > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > > with the > > > >> > no lock file option during configure, and that solved his problem. > > > >> > > > > >> > As this issue will probably take some time to get resolved across > > all the > > > >> > various Linux distros, it might be worth considering changing the > > default > > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > > >> > versions of the lib in the binary archive. > > > >> > > > > >> > Thanks for your indulgence > > > >> > > > > >> > Andy > > > >> > > > > >> > _______________________________________________ > > > >> > Rxtx mailing list > > > >> > Rxtx at qbang.org > > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > > >> > > > > >> > > > >> > > > >> > > > >> -- > > > >> Atte: > > > >> Daniel Dario Morales Salas > > > >> Ingeniero Civil en Computaci?n e Inform?tica > > > >> Tel?fono: 02 684 3417 > > > >> Celular: 09 643 1802 > > > >> Santiago, Chile > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at qbang.org > > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > > > -- > > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > > > WWW: http://www.sharms.org/blog > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From Bob_Jacobsen at lbl.gov Thu Feb 4 09:26:49 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Thu, 4 Feb 2010 08:26:49 -0800 Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 Message-ID: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're using RXTX-2.2pre2, although it emits the known message about "Version mismatch". WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 After the usual messing around, we've got it working on 11 Windows versions, multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ have things working rarely say so, so I don't know whether anybody has gotten it to work on 10.4 or not. The problem encountered is this: dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib dyld: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib followed by the JVM crashing hard. I've got those dump files if that would help. Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If so, is there a patch I can get and build? Thanks Bob -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From tjarvi at qbang.org Thu Feb 4 14:22:21 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 4 Feb 2010 14:22:21 -0700 (MST) Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 In-Reply-To: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> References: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> Message-ID: On Thu, 4 Feb 2010, Bob Jacobsen wrote: > We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're > using RXTX-2.2pre2, although it emits the known message about "Version > mismatch". > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > > After the usual messing around, we've got it working on 11 Windows versions, > multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with > a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ > have things working rarely say so, so I don't know whether anybody has gotten > it to work on 10.4 or not. > > The problem encountered is this: > > dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > dyld: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > followed by the JVM crashing hard. I've got those dump files if that would > help. > > Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If > so, is there a patch I can get and build? > Hi Bob, I talked to a coworker about the problem you ran into. It appears that it is possible to target 'older' Mac systems through makefile configuration changes. "Configuring a Makefile-Based Project If you have a makefile-based project, you can also take advantage of SDK-based development, by adding the appropriate options to your compile and link commands. Using SDKs in makefile-based projects requires GCC 4.0 or later. To choose an SDK, you use the -isysroot option with the compiler and the -syslibroot option with the linker. Both options require that you specify the full path to the desired SDK directory. To set the Deployment OS version in a makefile, use a makefile variable of the form: ENVP= MACOSX_DEPLOYMENT_TARGET=10.4. To use this variable in your makefile, include it in front of your compile and link commands." http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html Or build on the oldest system you want to support. -- Trent Jarvi tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Thu Feb 4 14:56:19 2010 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Thu, 4 Feb 2010 14:56:19 -0700 Subject: [Rxtx] RXTX on 64 Bit Redhat In-Reply-To: References: <4ec9eab61001281448g3dd84910r867619948a4e0d7a@mail.gmail.com> Message-ID: Trent -- Finally fixed all my build related issues. I ran into another issue. On one of my machines my JDK is returning multiple folders for the "java.ext.dirs" (java.ext.dirs -> /opt/jdk1.6.0_17/jre/lib/ext:/usr/java/packages/lib/ext) system property. As a result my JVM wasn't able to detect the gnu.io.rxtx.properties. I am attaching a patch for RXTXCommDriver.java file to check for multiple locations. Also i have to assign permission 660 to all my dev ports to be located by RXTX. Pawan ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 5:12 PM To: Trent Jarvi Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Here is the error i get when i build the src from release-2-1-7 -bash-3.2$ make ( \ \ cd i686-pc-linux-gnu; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/ jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I/opt/jav a1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec - c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialImp.lo;\ if [ "Serial" = "Serial" ]; then \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I /opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_tim espec -c /home/jb_stg/rxtx/rxtx-devel/./src/fuserImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ else \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo; \ fi; \ ) gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/inclu de -I/opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need _timespec -c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -fPIC -DPIC -o /hom e/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/.libs/SerialImp.o /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:25:29: error: gnu_io_RXTXPort.h: No such file or directory In file included from /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:113: /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:91: error: expected specifier-qua lifier-list before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'jobject' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:408: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:409: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:410: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:411: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:415: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:416: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:417: error: expected '=', ',', '; ', 'asm' or '__attribute__' before 'is_interrupted' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:418: error: expected declaration specifiers or '...' before 'jint' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:424: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:441: error: expected ')' before ' *' token ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 4:57 PM To: Santosh Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Santosh -- Thank you. That fixed the issue. All -- What CVS branch or release should i use to get the latest RXTX src code. Pawan ________________________________ From: Santosh [mailto:santosh.ry at gmail.com] Sent: Thursday, January 28, 2010 3:49 PM To: Kharbanda, Pawan Cc: Trent Jarvi; rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat error "./configure: /bin/sh^M: bad interpreter: No such file or directory". I think you need to run dos2unix on script files before compiling. Thanks, Santosh On Thu, Jan 28, 2010 at 5:33 PM, Kharbanda, Pawan > wrote: Trent -- We are upgrading our exisiting OS and JDK on a project that rely heavily on RXTX api's. We are now using JDK1.6 32 bit (build 1.6.0_17-b04) and RedHat 5 on a 64 bit machine. Linux tocrhstg02.dot.state.co.us 2.6.18-164.6.1.el5 #1 SMP Tue Oct 27 11:30:06 EDT 2009 i686 i686 i386 GNU/Linux Red Hat Enterprise Linux Server release 5.4 (Tikanga) I tried to run version 2.1.7 r2 on it but not able to see any of my Digi ports I was able to access only /dev/ttyS0 (physical ports). Not sure if the problem is with the Digi driver or RXTX. I tried to open a Digi port with minicom and it worked fine. I also tried to get latest from CVS (rxtx-devel) and when I do "configure" I see this error "./configure: /bin/sh^M: bad interpreter: No such file or directory". Can someone please help me with this? Thanks for the help. Pawan _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch.txt URL: From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 01:02:21 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 13:32:21 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> My serial port driver(apparently) does not support receive timeout.I registered an event listener for DATA_AVAILABLE. However, the control never seems to come out of the 'while' loop.Shouldn't the InputStream.read return a '-1' immediately if no data is available (this seems to be the default operation)? This was tried on a x86 Linux desktop using rxtx-2.1-7 I've added the snippet for clarity: /******************************************************************************************************************************************************************************/ mySerialPort.enableReceiveThreshold(2000);//Trying to set a time limit for read calls System.out.println(mySerialPort.isReceiveTimeoutEnabled()); // I get FALSE, so its not supported on hardware. mySerialPort.addEventListener(this); mySerialPort.notifyOnDataAvailable(true);//register a event with //my SerialEvent listener implementation: public void serialEvent(SerialPortEvent arg0) { int newData=0; switch(arg0.getEventType()){ case SerialPortEvent.DATA_AVAILABLE: while (newData != -1) { try { newData = is.read();//This should eventually return a -1 if no data is available within a timeout.PROBLEM!! System.out.println("Got a byte from port:"+newData); if (newData == -1) { break; } } catch (IOException ex) { System.err.println(ex); return; } } break; } return; } /******************************************************************************************************************************************************************************/ Thanks and regards, Ravi From michael.erskine at ketech.com Wed Feb 3 02:26:50 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 09:26:50 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From michael.erskine at ketech.com Wed Feb 3 05:03:30 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 12:03:30 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > Michael Erskine > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > > Your event handler should handle the event and return immediately so that its > controlling thread can handle other events. I recommend a single read in the > following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) > reads all available bytes up to the size of the buffer returning the number of > bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } After posting this I considered the glaring possibility of the rawbuf read buffer being too small to receive all the available bytes and perhaps skipping data: after all, I'm guessing that is why we see so many posts asking for help with blocking implementations of read event handlers looping on "while(bytes are available)". I've spent this morning writing an extensive multi-threaded unit test suite that includes tests with a tiny buffer compared to the amount of data available and found that no data was being skipped. I now want to know why! The SerialPortEvent.DATA_AVAILABLE event must be being fired again if there is more data available on the input stream. If that is the case then it should be heavily documented with good examples in the wiki to avoid the types of developer anguish we see so regularly. BTW: I'm not at liberty to post the JUnit tests as they use my company's unit test suite framework. Regards, Michael Erskine. From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 06:18:04 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 18:48:04 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Hello Michael, I tried out your suggestion but the problem is that the read(rawbuf) blocks until the entire length of the rawbuf array has been read (blocking). I cannot decide on a reasonable size of the array because it varies from 2 bytes to as much as 50 byes (i'm communicating with a modem,each response is of a different length), which is why i wanted to use non blocking calls. But on a side note, read(byte[]) in turn calls the read() in a loop.In the native C function, the read is supposed to return a -1 upon timeout.But my driver does not support timeout.The default timeout value is zero and the linux select call upon zero time out causes an infinite wait.What am i missing...... Thanks and regards, Ravi Date: Wed, 3 Feb 2010 09:26:50 +0000 From: Michael Erskine To: "rxtx at qbang.org" Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: Content-Type: text/plain; charset="us-ascii" > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From m.kirkland at comcast.net Wed Feb 3 06:46:03 2010 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 3 Feb 2010 05:46:03 -0800 Subject: [Rxtx] One port blocking another port In-Reply-To: References: Message-ID: <68768633814F4D7D86761D34F0764FE0@bengal.net> It turns out this is caused by having the RTS/CTS flow control turned on and me not providing a true on the RTS pin. Somehow it seems the port timing out on a read allows the write to proceed. This is not an issue for my application but I wonder if the write should not proceed until the RTS pin is true even if a read times out. mk -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Monday, January 25, 2010 7:48 PM To: Mike Kirkland Cc: rxtx at qbang.org Subject: Re: [Rxtx] One port blocking another port On Mon, 25 Jan 2010, Mike Kirkland wrote: > > Hi All, > > ? > > I have a program that reads from one com port and writes to another com > port. It also does the same thing in reverse (reads from the second com port > and writes to the first one. It basically ties two com ports together. > > ? > > One port is very chatty and has a consent stream of data. The other port has > very little data. > > ? > > Both ports use a 5000 ms (5 second) time out. > > ? > > The issue I am having is that is appears that the first port?s write to the > second port is blocked while the second port is waiting for input. The first > port?s write proceeds only after the second port has timed out. > > ? > > I suppose I could have something twisted around in my code but I was > wondering if this is a know issue? > Hi Kirk, I've not seen a report like this. Perhaps some simple reproduction code will reveal a problem on your end or help us identify a problem in rxtx. I think there are several users doing multiport communication. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Wed Feb 3 07:03:58 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:03:58 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Message-ID: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> 2010/2/3 Ravishankar N > Hello Michael, > [..] > But on a side note, read(byte[]) in turn calls the read() in a loop.In the > native C function, the read is supposed to return a -1 upon timeout.But my > driver > does not support timeout.The default timeout value is zero and the linux > select call upon zero time out causes an infinite wait.What am i > missing...... > > When I have tested RXTX between platforms, I have observed "hangup" inside JNI driver when no data in Linux, is normal thing. Solution was setting the timeout for RXTX when no data from JNI driver. Something like that: commPort.enableReceiveTimeout(10); And it works perfect.... The only difference is that I am NOT using events - I am using continous read in separate thread and if data is available, is parsed and transferred to application using exception. Regards Mariusz > Thanks and regards, > Ravi > > Date: Wed, 3 Feb 2010 09:26:50 +0000 > From: Michael Erskine > To: "rxtx at qbang.org" > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > Message-ID: > > > Content-Type: text/plain; charset="us-ascii" > > > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of > > Ravishankar N > > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > > > My serial port driver(apparently) does not support receive timeout.I > > registered an event listener for DATA_AVAILABLE. However, the control > never > > seems to come out of the 'while' loop.Shouldn't the > > InputStream.read return a '-1' immediately if no data is available (this > seems > > to be the default operation)? > > Your event handler should handle the event and return immediately so that > its controlling thread can handle other events. I recommend a single read in > the following manner: rawbuf is a byte[] of "reasonable" size and the > read(byte[]) reads all available bytes up to the size of the buffer > returning the number of bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } > > This style of reading has worked for me with RXTX on Linux and Windows XP > for a good few years now in railway industry communications systems. Any > timeouts (largely unnecessary in my applications) can be handled elsewhere, > usually at a higher layer. > > Regards, > Michael Erskine. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Feb 3 07:22:55 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 3 Feb 2010 09:22:55 -0500 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: I'm guessing that this is driver specific. I recently had to support a select()/poll() infrastructure for a linux serial DD, its certainly non trivial to support async IO, so I suspect the problem in this case has to do with missing poll infrastructure in the device driver. This also has to coupled with special open flags for the device (which is within the rxtx code) The key routines within a 2.6 kernel linux device driver are shown below (if you have access to it for your particular device) are indicated below (here is a snippet from my device driver c code that supports polling/select). User space code to test this shown below also, note that the device needs to be opened with the O_NONBLOCK option to support the select/poll api // device driver code ..... /* * File operations supported by this driver. */ static struct file_operations iop_fops = { .owner = THIS_MODULE, .check_flags= iop_check_flags, .ioctl = iop_ioctl, .open = iop_open, .poll = iop_poll, // SUPPORT FOR SELECT/POLL infrastructure .read = iop_read, .release = iop_release, .write = iop_write, }; /** * Select/poll/epoll infrastructure. * * @param file * @param wait * * @return */ static unsigned int iop_poll(struct file *filp, poll_table *wait) { struct iop_device *devp = (struct iop_device *)filp->private_data; // the poll_table wait arg is an opaque pointer poll_wait(filp, &devp->readq, wait); // return from poll indicating whether we have read/write data unsigned int mask = 0; if (kfifo_len(devp->rx_fifo)) { mask |= (POLLIN | POLLRDNORM); } // @JC We don't do select on write yet // if (kfifo_len(devp->tx_fifo)) { // mask |= (POLLOUT | POLLWRNORM); // } // Only print out while debugging // if (mask != 0) { // printk (KERN_INFO "%s: [%04x]\n", __FUNCTION__, mask); // } return mask; } /** * device driver blocking and non blocking read function. This * function reads the requested number of bytes from the read * kfifo blocking as required. * * @param filp * @param buf * @param count * @param f_pos * * @return */ static ssize_t iop_read(struct file *filp, char __user *buf, size_t count, loff_t * ppos) { // access appropriate device struct struct iop_device *devp = (struct iop_device *) filp->private_data; ssize_t retval; // support non blocking mode (default) by checking if the kfifo is empty first if ((kfifo_len(devp->rx_fifo)==0) && (filp->f_flags & O_NONBLOCK)) { return -EAGAIN; } // wait for rx_fifo to receive data via receive interrupts retval = wait_event_interruptible(devp->readq, kfifo_len(devp->rx_fifo) != 0); // check for some error condition if (retval) { printk (KERN_ERR "%s: wait_event_interruptible returned[%d]\n", __FUNCTION__, retval); return retval; } // copy max requested bytes from rx_fifo to device buffer // this may still leave bytes in the kfifo for a subsequent read // if we are reading in a loop retval = kfifo_get(devp->rx_fifo, devp->rxbuf, count); // printk (KERN_INFO "%s: [%d] byte(s)\n", __FUNCTION__, retval); if (copy_to_user(buf, devp->rxbuf, retval)) { printk (KERN_ERR "%s: problem copying rx_fifo data to user buffer\n", __FUNCTION__); return -EFAULT; } return retval; } // a selection of my user space code reading via select()/poll()..... // user space open code iop_fd = ::open( deviceName.data(), O_RDWR | O_NONBLOCK); while ((bytes_to_expect - bytes_read) > 0) { // must reinitialize these between select calls fd_set readfds; FD_ZERO( &readfds ); FD_SET( iop_fd, &readfds ); // 1s sec read polling timeout struct timeval timeout; timeout.tv_sec = 1; timeout.tv_usec = 0; int rc = select( FD_SETSIZE, &readfds, NULL, NULL, &timeout ); // read from file when descriptor // indicates data available without blocking if ((rc > 0) && FD_ISSET(iop_fd, &readfds)) { // read into the appropriate offset within the rx_buf int temp = read(iop_fd, rx_buf + bytes_read, bytes_to_expect - bytes_read); if (!temp) { printf("EOF detected with %d bytes expected\n", bytes_to_expect - bytes_read); } else { bytes_read += temp; } } else if (rc < 0){ printf("%s: select on [%s], bytes_read[%d], errno=%d\n", __FUNCTION__, thread_args->device, bytes_read, errno); } else { printf("%s: select on [%s], bytes_read[%d], timeout\n", __FUNCTION__, thread_args->device, bytes_read); } } On Wed, Feb 3, 2010 at 9:03 AM, Mariusz Dec wrote: > > > 2010/2/3 Ravishankar N > >> Hello Michael, >> [..] >> >> But on a side note, read(byte[]) in turn calls the read() in a loop.In the >> native C function, the read is supposed to return a -1 upon timeout.But my >> driver >> does not support timeout.The default timeout value is zero and the linux >> select call upon zero time out causes an infinite wait.What am i >> missing...... >> >> > When I have tested RXTX between platforms, I have observed "hangup" inside > JNI driver when no data in Linux, is normal thing. > > Solution was setting the timeout for RXTX when no data from JNI driver. > > Something like that: > > commPort.enableReceiveTimeout(10); > > And it works perfect.... > > The only difference is that I am NOT using events - I am using continous > read in separate thread and if data is available, is parsed and transferred > to application using exception. > > Regards > Mariusz > > > >> Thanks and regards, >> Ravi >> >> Date: Wed, 3 Feb 2010 09:26:50 +0000 >> From: Michael Erskine >> To: "rxtx at qbang.org" >> Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? >> Message-ID: >> >> >> Content-Type: text/plain; charset="us-ascii" >> >> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >> Of >> > Ravishankar N >> > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? >> > >> > My serial port driver(apparently) does not support receive timeout.I >> > registered an event listener for DATA_AVAILABLE. However, the control >> never >> > seems to come out of the 'while' loop.Shouldn't the >> > InputStream.read return a '-1' immediately if no data is available (this >> seems >> > to be the default operation)? >> >> Your event handler should handle the event and return immediately so that >> its controlling thread can handle other events. I recommend a single read in >> the following manner: rawbuf is a byte[] of "reasonable" size and the >> read(byte[]) reads all available bytes up to the size of the buffer >> returning the number of bytes actually read... >> >> case SerialPortEvent.DATA_AVAILABLE: >> try { >> int i = is.read(rawbuf); >> if (i == -1) { >> << process EOF condition - should never happen >> >> return; >> } >> << process bytes (rawbuf, i); >> >> return; >> } catch (IOException e) { >> << promptly deal with exception >> >> return; >> } >> >> This style of reading has worked for me with RXTX on Linux and Windows XP >> for a good few years now in railway industry communications systems. Any >> timeouts (largely unnecessary in my applications) can be handled elsewhere, >> usually at a higher layer. >> >> Regards, >> Michael Erskine. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Feb 3 07:33:27 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:33:27 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: <73a89f361002030633j682610afia48dc7accd8e049b@mail.gmail.com> 2010/2/3 John Coffey > I'm guessing that this is driver specific. I recently had to support a > select()/poll() infrastructure for a linux serial DD, its certainly non > trivial to support async IO, so I suspect the problem in this case has to do > with missing poll infrastructure in the device driver. This also has to > coupled with special open flags for the device (which is within the rxtx > code) > > Yes, you are right, it may be driver specific, but in my case I haven't changed blocking JNI driver. I have added ONLY one call to RXTX method mentioned in my previous post and blocking (as seen as from Java app) gone out... Maybe this is not elegant, but works without problem in my app. I am using only FTDI chips and their drivers from couple of years and maybe this is the kind of the way to have no many problems with serial as well? Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From andyrxtx at g0poy.co.uk Wed Feb 3 11:09:04 2010 From: andyrxtx at g0poy.co.uk (andyrxtx at g0poy.co.uk) Date: Wed, 3 Feb 2010 18:09:04 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes Message-ID: <20100203180904.164f24dd@workstation.site> ?Hello RXTX group, I have just joined this group, and this is my first posting. I wanted to pass on some information regarding rxtx, so apologies if this has been brought up before. I have searched back through the archives but nothing specific came up. I am not a Java programmer, and I only came across rxtx a few days ago. I use a piece of test equipment called a miniVNA http://www.miniradiosolutions.com/ This is a serial USB controlled instrument, and it has control software available for MS windows, and a very old and now non-working Linux application. A few days ago Dietmar, DL2SBA released a Java application to control the miniVNA, obviously this application makes use of rxtx. The program worked fine on Windows, so I set about installing it onto Linux. I use SUSE11.1 After a few false starts, I got the system running fairly easily, sorting out the file locking by adding the uucp group to the users account as suggested (I used the 2.2pre binary files) I then passed the install instructions onto another miniVNA user, who also uses SUSE, but he ran into problems. To cut a long story short, he was also having file lock problems, but the uucp fix did not work. Digging into his system I found that there have been some changes in SUSE 11.2. tty ports are now assigned to the dialout group rather than uucp. A hint in the rxtx INSTALL file, suggested that var/lock needs to be checked, so: SUSE 11.1, var/lock is root:uucp SUSE 11.2 var/lock is root:root A search on Google brought up several comments regarding this, and also a bugzilla entry. https://bugzilla.novell.com/show_bug.cgi?id=552095 However from reading the various posts, some of which are in the bugzilla entry, it appears that many distros may be, or have changed to this configuration, and this will undoubtedly break several things, rxtx included. I solved my fellow SUSE users problem by compiling the rxtx libs with the no lock file option during configure, and that solved his problem. As this issue will probably take some time to get resolved across all the various Linux distros, it might be worth considering changing the default on the Linux build of rxtx not to use lockfiles, or provide the two versions of the lib in the binary archive. Thanks for your indulgence Andy From damorales at gmail.com Wed Feb 3 11:33:23 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 15:33:23 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203180904.164f24dd@workstation.site> References: <20100203180904.164f24dd@workstation.site> Message-ID: Hi I had the same problem in Mandriva 2010 and yes, adding the user to the uucp group did not work as it used to be in earlier versions of linux distros, causing RXTX to not work as non root user. The problem appears because the existense of UDEV, now you MUST add a RULE so the group (uucp or whatever) have access (Read, Write, Execute) to the Serial Port. To solve the problem, without needing to recompile RXTX, you must add a rule to grant permissions (0666) to the group for the device or port (tty*, ttyUSB*, etc). I do not remember now what is the line i added but when i come back home i will give it to you (i am at work now). Greetings ! 2010/2/3 > Hello RXTX group, > > I have just joined this group, and this is my first posting. > I wanted to pass on some information regarding rxtx, so apologies if > this has been brought up before. I have searched back through the > archives but nothing specific came up. > > I am not a Java programmer, and I only came across rxtx a few days ago. > > I use a piece of test equipment called a miniVNA > http://www.miniradiosolutions.com/ > > This is a serial USB controlled instrument, and it has control software > available for MS windows, and a very old and now non-working Linux > application. > > A few days ago Dietmar, DL2SBA released a Java application to control the > miniVNA, obviously this application makes use of rxtx. > > The program worked fine on Windows, so I set about installing it onto > Linux. I use SUSE11.1 After a few false starts, I got the system running > fairly easily, sorting out the file locking by adding the uucp group to > the users account as suggested (I used the 2.2pre binary files) I then > passed the install instructions onto another miniVNA user, who also uses > SUSE, but he ran into problems. To cut a long story short, he was > also having file lock problems, but the uucp fix did not work. Digging > into his system I found that there have been some changes in SUSE 11.2. > > tty ports are now assigned to the dialout group rather than uucp. > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > checked, so: > > SUSE 11.1, var/lock is root:uucp > SUSE 11.2 var/lock is root:root > > A search on Google brought up several comments regarding this, and also > a bugzilla entry. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > However from reading the various posts, some of which are in the bugzilla > entry, it appears that many distros may be, or have changed to this > configuration, and this will undoubtedly break several things, rxtx > included. > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > no lock file option during configure, and that solved his problem. > > As this issue will probably take some time to get resolved across all the > various Linux distros, it might be worth considering changing the default > on the Linux build of rxtx not to use lockfiles, or provide the two > versions of the lib in the binary archive. > > Thanks for your indulgence > > Andy > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Wed Feb 3 12:07:02 2010 From: andy at g0poy.com (Andy Eskelson) Date: Wed, 3 Feb 2010 19:07:02 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> Message-ID: <20100203190702.1b0e7015@workstation.site> Thanks Daniel, I am aware of the permissions problem, I have had a udev rules to solve this for other programs for some time. . I don't think that this is the same problem. as far as I can understand things, the lock files are written in var/lock. Previously var/lock and dev/tty-whatever were the same group. Now with var/lock owned by and with a group of root:root anything other than root cannot create a lock file. Even minicom is broken by this change. This change is going to have quite a few knock-on effects I think. Andy On Wed, 3 Feb 2010 15:33:23 -0300 Daniel Morales Salas wrote: > Hi > > I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > group did not work as it used to be in earlier versions of linux distros, > causing RXTX to not work as non root user. > > The problem appears because the existense of UDEV, now you MUST add a RULE > so the group (uucp or whatever) have access (Read, Write, Execute) to the > Serial Port. > > To solve the problem, without needing to recompile RXTX, you must add a rule > to grant permissions (0666) to the group for the device or port (tty*, > ttyUSB*, etc). I do not remember now what is the line i added but when i > come back home i will give it to you (i am at work now). > > Greetings ! > > 2010/2/3 > > > Hello RXTX group, > > > > I have just joined this group, and this is my first posting. > > I wanted to pass on some information regarding rxtx, so apologies if > > this has been brought up before. I have searched back through the > > archives but nothing specific came up. > > > > I am not a Java programmer, and I only came across rxtx a few days ago. > > > > I use a piece of test equipment called a miniVNA > > http://www.miniradiosolutions.com/ > > > > This is a serial USB controlled instrument, and it has control software > > available for MS windows, and a very old and now non-working Linux > > application. > > > > A few days ago Dietmar, DL2SBA released a Java application to control the > > miniVNA, obviously this application makes use of rxtx. > > > > The program worked fine on Windows, so I set about installing it onto > > Linux. I use SUSE11.1 After a few false starts, I got the system running > > fairly easily, sorting out the file locking by adding the uucp group to > > the users account as suggested (I used the 2.2pre binary files) I then > > passed the install instructions onto another miniVNA user, who also uses > > SUSE, but he ran into problems. To cut a long story short, he was > > also having file lock problems, but the uucp fix did not work. Digging > > into his system I found that there have been some changes in SUSE 11.2. > > > > tty ports are now assigned to the dialout group rather than uucp. > > > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > checked, so: > > > > SUSE 11.1, var/lock is root:uucp > > SUSE 11.2 var/lock is root:root > > > > A search on Google brought up several comments regarding this, and also > > a bugzilla entry. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > However from reading the various posts, some of which are in the bugzilla > > entry, it appears that many distros may be, or have changed to this > > configuration, and this will undoubtedly break several things, rxtx > > included. > > > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > > no lock file option during configure, and that solved his problem. > > > > As this issue will probably take some time to get resolved across all the > > various Linux distros, it might be worth considering changing the default > > on the Linux build of rxtx not to use lockfiles, or provide the two > > versions of the lib in the binary archive. > > > > Thanks for your indulgence > > > > Andy > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From thisdyingdream at gmail.com Wed Feb 3 12:32:35 2010 From: thisdyingdream at gmail.com (Steven Harms) Date: Wed, 3 Feb 2010 14:32:35 -0500 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203190702.1b0e7015@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: This is currently a bug in OpenSUSE that affects more than just rxtx, and is a result of unified udev rules. You can work around this by making udev change the group back to uucp until something more happens. https://bugzilla.novell.com/show_bug.cgi?id=552095 Thanks, Steve On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > Thanks Daniel, > > I am aware of the permissions problem, I have had a udev rules to solve > this for other programs for some time. > . > I don't think that this is the same problem. as far as I can understand > things, the lock files are written in var/lock. Previously var/lock and > dev/tty-whatever were the same group. Now with var/lock owned by and with > a group of root:root anything other than root cannot create a lock > file. Even minicom is broken by this change. > > This change is going to have quite a few knock-on effects I think. > > > Andy > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > Daniel Morales Salas wrote: > >> Hi >> >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp >> group did not work as it used to be in earlier versions of linux distros, >> causing RXTX to not work as non root user. >> >> The problem appears because the existense of UDEV, now you MUST add a RULE >> so the group (uucp or whatever) have access (Read, Write, Execute) to the >> Serial Port. >> >> To solve the problem, without needing to recompile RXTX, you must add a rule >> to grant permissions (0666) to the group for the device or port (tty*, >> ttyUSB*, etc). I do not remember now what is the line i added but when i >> come back home i will give it to you (i am at work now). >> >> Greetings ! >> >> 2010/2/3 >> >> > Hello RXTX group, >> > >> > I have just joined this group, and this is my first posting. >> > I wanted to pass on ?some information regarding rxtx, so apologies if >> > this has been brought up before. I have searched back through the >> > archives but nothing specific came up. >> > >> > I am not a Java programmer, and I only came across rxtx a few days ago. >> > >> > I use a piece of test equipment called a miniVNA >> > http://www.miniradiosolutions.com/ >> > >> > This is a serial USB controlled instrument, and it has control software >> > available for MS windows, and a very old and now non-working Linux >> > application. >> > >> > A few days ago Dietmar, DL2SBA released a Java application to control the >> > miniVNA, obviously this application makes use of rxtx. >> > >> > The program worked fine on Windows, so I set about installing it onto >> > Linux. I use SUSE11.1 After a few false starts, I got the system running >> > fairly easily, sorting out the file locking by adding the uucp group to >> > the users account as suggested (I used the 2.2pre binary files) I then >> > passed the install instructions onto another miniVNA user, who also uses >> > SUSE, but he ran into problems. To cut a long story short, he was >> > also having file lock problems, but the uucp fix did not work. Digging >> > into his system I found that there have been some changes in SUSE 11.2. >> > >> > tty ports are now assigned to the dialout group rather than uucp. >> > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be >> > checked, so: >> > >> > SUSE 11.1, var/lock is root:uucp >> > SUSE 11.2 var/lock is root:root >> > >> > A search on Google brought up several comments regarding this, and also >> > a ?bugzilla entry. >> > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 >> > >> > However from reading the various posts, some of which are in the bugzilla >> > entry, it appears that many distros may be, or have changed to this >> > configuration, and this will undoubtedly break several things, rxtx >> > included. >> > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the >> > no lock file option during configure, and that solved his problem. >> > >> > As this issue will probably take some time to get resolved across all the >> > various Linux distros, it might be worth considering changing the default >> > on the Linux build of rxtx not to use lockfiles, or provide the two >> > versions of the lib in the binary archive. >> > >> > Thanks for your indulgence >> > >> > Andy >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> >> >> >> -- >> Atte: >> Daniel Dario Morales Salas >> Ingeniero Civil en Computaci?n e Inform?tica >> Tel?fono: 02 684 3417 >> Celular: 09 643 1802 >> Santiago, Chile > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 WWW: http://www.sharms.org/blog From andy at g0poy.com Wed Feb 3 17:58:29 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 00:58:29 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: <20100204005829.7dc944e1@workstation.site> Thanks Steve, changing the serial ports back the uucp is not a big problem. I have a udev rule that can be easily modified already. However I cannot see any way of dealing with the var/lock problem apart from making it writable to all. Any thoughts? Andy On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms wrote: > This is currently a bug in OpenSUSE that affects more than just rxtx, > and is a result of unified udev rules. You can work around this by > making udev change the group back to uucp until something more > happens. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > Thanks, > > Steve > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > Thanks Daniel, > > > > I am aware of the permissions problem, I have had a udev rules to solve > > this for other programs for some time. > > . > > I don't think that this is the same problem. as far as I can understand > > things, the lock files are written in var/lock. Previously var/lock and > > dev/tty-whatever were the same group. Now with var/lock owned by and with > > a group of root:root anything other than root cannot create a lock > > file. Even minicom is broken by this change. > > > > This change is going to have quite a few knock-on effects I think. > > > > > > Andy > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > Daniel Morales Salas wrote: > > > >> Hi > >> > >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > >> group did not work as it used to be in earlier versions of linux distros, > >> causing RXTX to not work as non root user. > >> > >> The problem appears because the existense of UDEV, now you MUST add a RULE > >> so the group (uucp or whatever) have access (Read, Write, Execute) to the > >> Serial Port. > >> > >> To solve the problem, without needing to recompile RXTX, you must add a rule > >> to grant permissions (0666) to the group for the device or port (tty*, > >> ttyUSB*, etc). I do not remember now what is the line i added but when i > >> come back home i will give it to you (i am at work now). > >> > >> Greetings ! > >> > >> 2010/2/3 > >> > >> > Hello RXTX group, > >> > > >> > I have just joined this group, and this is my first posting. > >> > I wanted to pass on ?some information regarding rxtx, so apologies if > >> > this has been brought up before. I have searched back through the > >> > archives but nothing specific came up. > >> > > >> > I am not a Java programmer, and I only came across rxtx a few days ago. > >> > > >> > I use a piece of test equipment called a miniVNA > >> > http://www.miniradiosolutions.com/ > >> > > >> > This is a serial USB controlled instrument, and it has control software > >> > available for MS windows, and a very old and now non-working Linux > >> > application. > >> > > >> > A few days ago Dietmar, DL2SBA released a Java application to control the > >> > miniVNA, obviously this application makes use of rxtx. > >> > > >> > The program worked fine on Windows, so I set about installing it onto > >> > Linux. I use SUSE11.1 After a few false starts, I got the system running > >> > fairly easily, sorting out the file locking by adding the uucp group to > >> > the users account as suggested (I used the 2.2pre binary files) I then > >> > passed the install instructions onto another miniVNA user, who also uses > >> > SUSE, but he ran into problems. To cut a long story short, he was > >> > also having file lock problems, but the uucp fix did not work. Digging > >> > into his system I found that there have been some changes in SUSE 11.2. > >> > > >> > tty ports are now assigned to the dialout group rather than uucp. > >> > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > >> > checked, so: > >> > > >> > SUSE 11.1, var/lock is root:uucp > >> > SUSE 11.2 var/lock is root:root > >> > > >> > A search on Google brought up several comments regarding this, and also > >> > a ?bugzilla entry. > >> > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > >> > > >> > However from reading the various posts, some of which are in the bugzilla > >> > entry, it appears that many distros may be, or have changed to this > >> > configuration, and this will undoubtedly break several things, rxtx > >> > included. > >> > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the > >> > no lock file option during configure, and that solved his problem. > >> > > >> > As this issue will probably take some time to get resolved across all the > >> > various Linux distros, it might be worth considering changing the default > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > >> > versions of the lib in the binary archive. > >> > > >> > Thanks for your indulgence > >> > > >> > Andy > >> > > >> > _______________________________________________ > >> > Rxtx mailing list > >> > Rxtx at qbang.org > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > >> > >> > >> > >> -- > >> Atte: > >> Daniel Dario Morales Salas > >> Ingeniero Civil en Computaci?n e Inform?tica > >> Tel?fono: 02 684 3417 > >> Celular: 09 643 1802 > >> Santiago, Chile > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > WWW: http://www.sharms.org/blog From damorales at gmail.com Wed Feb 3 18:26:38 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 22:26:38 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100204005829.7dc944e1@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: Hello I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva 2010 this is what i get: drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ and i don't have ANY problem with lock files and RXTX in my java software. All i had to do was add this rule to udev: # serial KERNEL=="tty*", GROUP="uucp", MODE="0666" and that was all. Of course my user (metalklesk) is part of uucp group. I did not make /var/lock writable to all users. Greetings ! 2010/2/3 Andy Eskelson > Thanks Steve, > > changing the serial ports back the uucp is not a big problem. I have a > udev rule that can be easily modified already. However I cannot see any > way of dealing with the var/lock problem apart from making it writable to > all. Any thoughts? > > Andy > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > wrote: > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > and is a result of unified udev rules. You can work around this by > > making udev change the group back to uucp until something more > > happens. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > Thanks, > > > > Steve > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > Thanks Daniel, > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > this for other programs for some time. > > > . > > > I don't think that this is the same problem. as far as I can understand > > > things, the lock files are written in var/lock. Previously var/lock and > > > dev/tty-whatever were the same group. Now with var/lock owned by and > with > > > a group of root:root anything other than root cannot create a lock > > > file. Even minicom is broken by this change. > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > Daniel Morales Salas wrote: > > > > > >> Hi > > >> > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > the uucp > > >> group did not work as it used to be in earlier versions of linux > distros, > > >> causing RXTX to not work as non root user. > > >> > > >> The problem appears because the existense of UDEV, now you MUST add a > RULE > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > the > > >> Serial Port. > > >> > > >> To solve the problem, without needing to recompile RXTX, you must add > a rule > > >> to grant permissions (0666) to the group for the device or port (tty*, > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > i > > >> come back home i will give it to you (i am at work now). > > >> > > >> Greetings ! > > >> > > >> 2010/2/3 > > >> > > >> > Hello RXTX group, > > >> > > > >> > I have just joined this group, and this is my first posting. > > >> > I wanted to pass on some information regarding rxtx, so apologies > if > > >> > this has been brought up before. I have searched back through the > > >> > archives but nothing specific came up. > > >> > > > >> > I am not a Java programmer, and I only came across rxtx a few days > ago. > > >> > > > >> > I use a piece of test equipment called a miniVNA > > >> > http://www.miniradiosolutions.com/ > > >> > > > >> > This is a serial USB controlled instrument, and it has control > software > > >> > available for MS windows, and a very old and now non-working Linux > > >> > application. > > >> > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > control the > > >> > miniVNA, obviously this application makes use of rxtx. > > >> > > > >> > The program worked fine on Windows, so I set about installing it > onto > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > running > > >> > fairly easily, sorting out the file locking by adding the uucp group > to > > >> > the users account as suggested (I used the 2.2pre binary files) I > then > > >> > passed the install instructions onto another miniVNA user, who also > uses > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > >> > also having file lock problems, but the uucp fix did not work. > Digging > > >> > into his system I found that there have been some changes in SUSE > 11.2. > > >> > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > >> > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > >> > checked, so: > > >> > > > >> > SUSE 11.1, var/lock is root:uucp > > >> > SUSE 11.2 var/lock is root:root > > >> > > > >> > A search on Google brought up several comments regarding this, and > also > > >> > a bugzilla entry. > > >> > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > >> > > > >> > However from reading the various posts, some of which are in the > bugzilla > > >> > entry, it appears that many distros may be, or have changed to this > > >> > configuration, and this will undoubtedly break several things, rxtx > > >> > included. > > >> > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > with the > > >> > no lock file option during configure, and that solved his problem. > > >> > > > >> > As this issue will probably take some time to get resolved across > all the > > >> > various Linux distros, it might be worth considering changing the > default > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > >> > versions of the lib in the binary archive. > > >> > > > >> > Thanks for your indulgence > > >> > > > >> > Andy > > >> > > > >> > _______________________________________________ > > >> > Rxtx mailing list > > >> > Rxtx at qbang.org > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > >> > > > >> > > >> > > >> > > >> -- > > >> Atte: > > >> Daniel Dario Morales Salas > > >> Ingeniero Civil en Computaci?n e Inform?tica > > >> Tel?fono: 02 684 3417 > > >> Celular: 09 643 1802 > > >> Santiago, Chile > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at qbang.org > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > -- > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > WWW: http://www.sharms.org/blog > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Thu Feb 4 05:31:46 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 12:31:46 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: <20100204123146.6cffeb67@workstation.site> Thank's for the confirmation. Something odd is going on somewhere in SUSE 11.2. I'll have to build up a local SUSE11.2 system to see if I can nail down exactly what is going on. Something is blocking the lockfiles in var/lock. The net is nice, but it's a bit difficult trying to work out what is going on what the machine in question is in Germany and I'm in the UK :-) Andy On Wed, 3 Feb 2010 22:26:38 -0300 Daniel Morales Salas wrote: > Hello > > I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva > 2010 this is what i get: > > drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ > > and i don't have ANY problem with lock files and RXTX in my java software. > All i had to do was add this rule to udev: > > # serial > KERNEL=="tty*", GROUP="uucp", MODE="0666" > > and that was all. Of course my user (metalklesk) is part of uucp group. > I did not make /var/lock writable to all users. > > Greetings ! > > 2010/2/3 Andy Eskelson > > > Thanks Steve, > > > > changing the serial ports back the uucp is not a big problem. I have a > > udev rule that can be easily modified already. However I cannot see any > > way of dealing with the var/lock problem apart from making it writable to > > all. Any thoughts? > > > > Andy > > > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > > wrote: > > > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > > and is a result of unified udev rules. You can work around this by > > > making udev change the group back to uucp until something more > > > happens. > > > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > > > Thanks, > > > > > > Steve > > > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > > Thanks Daniel, > > > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > > this for other programs for some time. > > > > . > > > > I don't think that this is the same problem. as far as I can understand > > > > things, the lock files are written in var/lock. Previously var/lock and > > > > dev/tty-whatever were the same group. Now with var/lock owned by and > > with > > > > a group of root:root anything other than root cannot create a lock > > > > file. Even minicom is broken by this change. > > > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > > Daniel Morales Salas wrote: > > > > > > > >> Hi > > > >> > > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > > the uucp > > > >> group did not work as it used to be in earlier versions of linux > > distros, > > > >> causing RXTX to not work as non root user. > > > >> > > > >> The problem appears because the existense of UDEV, now you MUST add a > > RULE > > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > > the > > > >> Serial Port. > > > >> > > > >> To solve the problem, without needing to recompile RXTX, you must add > > a rule > > > >> to grant permissions (0666) to the group for the device or port (tty*, > > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > > i > > > >> come back home i will give it to you (i am at work now). > > > >> > > > >> Greetings ! > > > >> > > > >> 2010/2/3 > > > >> > > > >> > Hello RXTX group, > > > >> > > > > >> > I have just joined this group, and this is my first posting. > > > >> > I wanted to pass on some information regarding rxtx, so apologies > > if > > > >> > this has been brought up before. I have searched back through the > > > >> > archives but nothing specific came up. > > > >> > > > > >> > I am not a Java programmer, and I only came across rxtx a few days > > ago. > > > >> > > > > >> > I use a piece of test equipment called a miniVNA > > > >> > http://www.miniradiosolutions.com/ > > > >> > > > > >> > This is a serial USB controlled instrument, and it has control > > software > > > >> > available for MS windows, and a very old and now non-working Linux > > > >> > application. > > > >> > > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > > control the > > > >> > miniVNA, obviously this application makes use of rxtx. > > > >> > > > > >> > The program worked fine on Windows, so I set about installing it > > onto > > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > > running > > > >> > fairly easily, sorting out the file locking by adding the uucp group > > to > > > >> > the users account as suggested (I used the 2.2pre binary files) I > > then > > > >> > passed the install instructions onto another miniVNA user, who also > > uses > > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > > >> > also having file lock problems, but the uucp fix did not work. > > Digging > > > >> > into his system I found that there have been some changes in SUSE > > 11.2. > > > >> > > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > > >> > > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > > >> > checked, so: > > > >> > > > > >> > SUSE 11.1, var/lock is root:uucp > > > >> > SUSE 11.2 var/lock is root:root > > > >> > > > > >> > A search on Google brought up several comments regarding this, and > > also > > > >> > a bugzilla entry. > > > >> > > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > >> > > > > >> > However from reading the various posts, some of which are in the > > bugzilla > > > >> > entry, it appears that many distros may be, or have changed to this > > > >> > configuration, and this will undoubtedly break several things, rxtx > > > >> > included. > > > >> > > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > > with the > > > >> > no lock file option during configure, and that solved his problem. > > > >> > > > > >> > As this issue will probably take some time to get resolved across > > all the > > > >> > various Linux distros, it might be worth considering changing the > > default > > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > > >> > versions of the lib in the binary archive. > > > >> > > > > >> > Thanks for your indulgence > > > >> > > > > >> > Andy > > > >> > > > > >> > _______________________________________________ > > > >> > Rxtx mailing list > > > >> > Rxtx at qbang.org > > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > > >> > > > > >> > > > >> > > > >> > > > >> -- > > > >> Atte: > > > >> Daniel Dario Morales Salas > > > >> Ingeniero Civil en Computaci?n e Inform?tica > > > >> Tel?fono: 02 684 3417 > > > >> Celular: 09 643 1802 > > > >> Santiago, Chile > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at qbang.org > > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > > > -- > > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > > > WWW: http://www.sharms.org/blog > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From Bob_Jacobsen at lbl.gov Thu Feb 4 09:26:49 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Thu, 4 Feb 2010 08:26:49 -0800 Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 Message-ID: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're using RXTX-2.2pre2, although it emits the known message about "Version mismatch". WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 After the usual messing around, we've got it working on 11 Windows versions, multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ have things working rarely say so, so I don't know whether anybody has gotten it to work on 10.4 or not. The problem encountered is this: dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib dyld: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib followed by the JVM crashing hard. I've got those dump files if that would help. Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If so, is there a patch I can get and build? Thanks Bob -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From tjarvi at qbang.org Thu Feb 4 14:22:21 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 4 Feb 2010 14:22:21 -0700 (MST) Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 In-Reply-To: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> References: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> Message-ID: On Thu, 4 Feb 2010, Bob Jacobsen wrote: > We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're > using RXTX-2.2pre2, although it emits the known message about "Version > mismatch". > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > > After the usual messing around, we've got it working on 11 Windows versions, > multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with > a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ > have things working rarely say so, so I don't know whether anybody has gotten > it to work on 10.4 or not. > > The problem encountered is this: > > dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > dyld: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > followed by the JVM crashing hard. I've got those dump files if that would > help. > > Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If > so, is there a patch I can get and build? > Hi Bob, I talked to a coworker about the problem you ran into. It appears that it is possible to target 'older' Mac systems through makefile configuration changes. "Configuring a Makefile-Based Project If you have a makefile-based project, you can also take advantage of SDK-based development, by adding the appropriate options to your compile and link commands. Using SDKs in makefile-based projects requires GCC 4.0 or later. To choose an SDK, you use the -isysroot option with the compiler and the -syslibroot option with the linker. Both options require that you specify the full path to the desired SDK directory. To set the Deployment OS version in a makefile, use a makefile variable of the form: ENVP= MACOSX_DEPLOYMENT_TARGET=10.4. To use this variable in your makefile, include it in front of your compile and link commands." http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html Or build on the oldest system you want to support. -- Trent Jarvi tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Thu Feb 4 14:56:19 2010 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Thu, 4 Feb 2010 14:56:19 -0700 Subject: [Rxtx] RXTX on 64 Bit Redhat In-Reply-To: References: <4ec9eab61001281448g3dd84910r867619948a4e0d7a@mail.gmail.com> Message-ID: Trent -- Finally fixed all my build related issues. I ran into another issue. On one of my machines my JDK is returning multiple folders for the "java.ext.dirs" (java.ext.dirs -> /opt/jdk1.6.0_17/jre/lib/ext:/usr/java/packages/lib/ext) system property. As a result my JVM wasn't able to detect the gnu.io.rxtx.properties. I am attaching a patch for RXTXCommDriver.java file to check for multiple locations. Also i have to assign permission 660 to all my dev ports to be located by RXTX. Pawan ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 5:12 PM To: Trent Jarvi Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Here is the error i get when i build the src from release-2-1-7 -bash-3.2$ make ( \ \ cd i686-pc-linux-gnu; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/ jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I/opt/jav a1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec - c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialImp.lo;\ if [ "Serial" = "Serial" ]; then \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I /opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_tim espec -c /home/jb_stg/rxtx/rxtx-devel/./src/fuserImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ else \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo; \ fi; \ ) gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/inclu de -I/opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need _timespec -c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -fPIC -DPIC -o /hom e/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/.libs/SerialImp.o /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:25:29: error: gnu_io_RXTXPort.h: No such file or directory In file included from /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:113: /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:91: error: expected specifier-qua lifier-list before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'jobject' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:408: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:409: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:410: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:411: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:415: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:416: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:417: error: expected '=', ',', '; ', 'asm' or '__attribute__' before 'is_interrupted' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:418: error: expected declaration specifiers or '...' before 'jint' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:424: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:441: error: expected ')' before ' *' token ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 4:57 PM To: Santosh Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Santosh -- Thank you. That fixed the issue. All -- What CVS branch or release should i use to get the latest RXTX src code. Pawan ________________________________ From: Santosh [mailto:santosh.ry at gmail.com] Sent: Thursday, January 28, 2010 3:49 PM To: Kharbanda, Pawan Cc: Trent Jarvi; rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat error "./configure: /bin/sh^M: bad interpreter: No such file or directory". I think you need to run dos2unix on script files before compiling. Thanks, Santosh On Thu, Jan 28, 2010 at 5:33 PM, Kharbanda, Pawan > wrote: Trent -- We are upgrading our exisiting OS and JDK on a project that rely heavily on RXTX api's. We are now using JDK1.6 32 bit (build 1.6.0_17-b04) and RedHat 5 on a 64 bit machine. Linux tocrhstg02.dot.state.co.us 2.6.18-164.6.1.el5 #1 SMP Tue Oct 27 11:30:06 EDT 2009 i686 i686 i386 GNU/Linux Red Hat Enterprise Linux Server release 5.4 (Tikanga) I tried to run version 2.1.7 r2 on it but not able to see any of my Digi ports I was able to access only /dev/ttyS0 (physical ports). Not sure if the problem is with the Digi driver or RXTX. I tried to open a Digi port with minicom and it worked fine. I also tried to get latest from CVS (rxtx-devel) and when I do "configure" I see this error "./configure: /bin/sh^M: bad interpreter: No such file or directory". Can someone please help me with this? Thanks for the help. Pawan _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch.txt URL: From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 01:02:21 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 13:32:21 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> My serial port driver(apparently) does not support receive timeout.I registered an event listener for DATA_AVAILABLE. However, the control never seems to come out of the 'while' loop.Shouldn't the InputStream.read return a '-1' immediately if no data is available (this seems to be the default operation)? This was tried on a x86 Linux desktop using rxtx-2.1-7 I've added the snippet for clarity: /******************************************************************************************************************************************************************************/ mySerialPort.enableReceiveThreshold(2000);//Trying to set a time limit for read calls System.out.println(mySerialPort.isReceiveTimeoutEnabled()); // I get FALSE, so its not supported on hardware. mySerialPort.addEventListener(this); mySerialPort.notifyOnDataAvailable(true);//register a event with //my SerialEvent listener implementation: public void serialEvent(SerialPortEvent arg0) { int newData=0; switch(arg0.getEventType()){ case SerialPortEvent.DATA_AVAILABLE: while (newData != -1) { try { newData = is.read();//This should eventually return a -1 if no data is available within a timeout.PROBLEM!! System.out.println("Got a byte from port:"+newData); if (newData == -1) { break; } } catch (IOException ex) { System.err.println(ex); return; } } break; } return; } /******************************************************************************************************************************************************************************/ Thanks and regards, Ravi From michael.erskine at ketech.com Wed Feb 3 02:26:50 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 09:26:50 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From michael.erskine at ketech.com Wed Feb 3 05:03:30 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 12:03:30 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > Michael Erskine > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > > Your event handler should handle the event and return immediately so that its > controlling thread can handle other events. I recommend a single read in the > following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) > reads all available bytes up to the size of the buffer returning the number of > bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } After posting this I considered the glaring possibility of the rawbuf read buffer being too small to receive all the available bytes and perhaps skipping data: after all, I'm guessing that is why we see so many posts asking for help with blocking implementations of read event handlers looping on "while(bytes are available)". I've spent this morning writing an extensive multi-threaded unit test suite that includes tests with a tiny buffer compared to the amount of data available and found that no data was being skipped. I now want to know why! The SerialPortEvent.DATA_AVAILABLE event must be being fired again if there is more data available on the input stream. If that is the case then it should be heavily documented with good examples in the wiki to avoid the types of developer anguish we see so regularly. BTW: I'm not at liberty to post the JUnit tests as they use my company's unit test suite framework. Regards, Michael Erskine. From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 06:18:04 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 18:48:04 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Hello Michael, I tried out your suggestion but the problem is that the read(rawbuf) blocks until the entire length of the rawbuf array has been read (blocking). I cannot decide on a reasonable size of the array because it varies from 2 bytes to as much as 50 byes (i'm communicating with a modem,each response is of a different length), which is why i wanted to use non blocking calls. But on a side note, read(byte[]) in turn calls the read() in a loop.In the native C function, the read is supposed to return a -1 upon timeout.But my driver does not support timeout.The default timeout value is zero and the linux select call upon zero time out causes an infinite wait.What am i missing...... Thanks and regards, Ravi Date: Wed, 3 Feb 2010 09:26:50 +0000 From: Michael Erskine To: "rxtx at qbang.org" Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: Content-Type: text/plain; charset="us-ascii" > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From m.kirkland at comcast.net Wed Feb 3 06:46:03 2010 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 3 Feb 2010 05:46:03 -0800 Subject: [Rxtx] One port blocking another port In-Reply-To: References: Message-ID: <68768633814F4D7D86761D34F0764FE0@bengal.net> It turns out this is caused by having the RTS/CTS flow control turned on and me not providing a true on the RTS pin. Somehow it seems the port timing out on a read allows the write to proceed. This is not an issue for my application but I wonder if the write should not proceed until the RTS pin is true even if a read times out. mk -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Monday, January 25, 2010 7:48 PM To: Mike Kirkland Cc: rxtx at qbang.org Subject: Re: [Rxtx] One port blocking another port On Mon, 25 Jan 2010, Mike Kirkland wrote: > > Hi All, > > ? > > I have a program that reads from one com port and writes to another com > port. It also does the same thing in reverse (reads from the second com port > and writes to the first one. It basically ties two com ports together. > > ? > > One port is very chatty and has a consent stream of data. The other port has > very little data. > > ? > > Both ports use a 5000 ms (5 second) time out. > > ? > > The issue I am having is that is appears that the first port?s write to the > second port is blocked while the second port is waiting for input. The first > port?s write proceeds only after the second port has timed out. > > ? > > I suppose I could have something twisted around in my code but I was > wondering if this is a know issue? > Hi Kirk, I've not seen a report like this. Perhaps some simple reproduction code will reveal a problem on your end or help us identify a problem in rxtx. I think there are several users doing multiport communication. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Wed Feb 3 07:03:58 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:03:58 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Message-ID: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> 2010/2/3 Ravishankar N > Hello Michael, > [..] > But on a side note, read(byte[]) in turn calls the read() in a loop.In the > native C function, the read is supposed to return a -1 upon timeout.But my > driver > does not support timeout.The default timeout value is zero and the linux > select call upon zero time out causes an infinite wait.What am i > missing...... > > When I have tested RXTX between platforms, I have observed "hangup" inside JNI driver when no data in Linux, is normal thing. Solution was setting the timeout for RXTX when no data from JNI driver. Something like that: commPort.enableReceiveTimeout(10); And it works perfect.... The only difference is that I am NOT using events - I am using continous read in separate thread and if data is available, is parsed and transferred to application using exception. Regards Mariusz > Thanks and regards, > Ravi > > Date: Wed, 3 Feb 2010 09:26:50 +0000 > From: Michael Erskine > To: "rxtx at qbang.org" > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > Message-ID: > > > Content-Type: text/plain; charset="us-ascii" > > > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of > > Ravishankar N > > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > > > My serial port driver(apparently) does not support receive timeout.I > > registered an event listener for DATA_AVAILABLE. However, the control > never > > seems to come out of the 'while' loop.Shouldn't the > > InputStream.read return a '-1' immediately if no data is available (this > seems > > to be the default operation)? > > Your event handler should handle the event and return immediately so that > its controlling thread can handle other events. I recommend a single read in > the following manner: rawbuf is a byte[] of "reasonable" size and the > read(byte[]) reads all available bytes up to the size of the buffer > returning the number of bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } > > This style of reading has worked for me with RXTX on Linux and Windows XP > for a good few years now in railway industry communications systems. Any > timeouts (largely unnecessary in my applications) can be handled elsewhere, > usually at a higher layer. > > Regards, > Michael Erskine. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Feb 3 07:22:55 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 3 Feb 2010 09:22:55 -0500 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: I'm guessing that this is driver specific. I recently had to support a select()/poll() infrastructure for a linux serial DD, its certainly non trivial to support async IO, so I suspect the problem in this case has to do with missing poll infrastructure in the device driver. This also has to coupled with special open flags for the device (which is within the rxtx code) The key routines within a 2.6 kernel linux device driver are shown below (if you have access to it for your particular device) are indicated below (here is a snippet from my device driver c code that supports polling/select). User space code to test this shown below also, note that the device needs to be opened with the O_NONBLOCK option to support the select/poll api // device driver code ..... /* * File operations supported by this driver. */ static struct file_operations iop_fops = { .owner = THIS_MODULE, .check_flags= iop_check_flags, .ioctl = iop_ioctl, .open = iop_open, .poll = iop_poll, // SUPPORT FOR SELECT/POLL infrastructure .read = iop_read, .release = iop_release, .write = iop_write, }; /** * Select/poll/epoll infrastructure. * * @param file * @param wait * * @return */ static unsigned int iop_poll(struct file *filp, poll_table *wait) { struct iop_device *devp = (struct iop_device *)filp->private_data; // the poll_table wait arg is an opaque pointer poll_wait(filp, &devp->readq, wait); // return from poll indicating whether we have read/write data unsigned int mask = 0; if (kfifo_len(devp->rx_fifo)) { mask |= (POLLIN | POLLRDNORM); } // @JC We don't do select on write yet // if (kfifo_len(devp->tx_fifo)) { // mask |= (POLLOUT | POLLWRNORM); // } // Only print out while debugging // if (mask != 0) { // printk (KERN_INFO "%s: [%04x]\n", __FUNCTION__, mask); // } return mask; } /** * device driver blocking and non blocking read function. This * function reads the requested number of bytes from the read * kfifo blocking as required. * * @param filp * @param buf * @param count * @param f_pos * * @return */ static ssize_t iop_read(struct file *filp, char __user *buf, size_t count, loff_t * ppos) { // access appropriate device struct struct iop_device *devp = (struct iop_device *) filp->private_data; ssize_t retval; // support non blocking mode (default) by checking if the kfifo is empty first if ((kfifo_len(devp->rx_fifo)==0) && (filp->f_flags & O_NONBLOCK)) { return -EAGAIN; } // wait for rx_fifo to receive data via receive interrupts retval = wait_event_interruptible(devp->readq, kfifo_len(devp->rx_fifo) != 0); // check for some error condition if (retval) { printk (KERN_ERR "%s: wait_event_interruptible returned[%d]\n", __FUNCTION__, retval); return retval; } // copy max requested bytes from rx_fifo to device buffer // this may still leave bytes in the kfifo for a subsequent read // if we are reading in a loop retval = kfifo_get(devp->rx_fifo, devp->rxbuf, count); // printk (KERN_INFO "%s: [%d] byte(s)\n", __FUNCTION__, retval); if (copy_to_user(buf, devp->rxbuf, retval)) { printk (KERN_ERR "%s: problem copying rx_fifo data to user buffer\n", __FUNCTION__); return -EFAULT; } return retval; } // a selection of my user space code reading via select()/poll()..... // user space open code iop_fd = ::open( deviceName.data(), O_RDWR | O_NONBLOCK); while ((bytes_to_expect - bytes_read) > 0) { // must reinitialize these between select calls fd_set readfds; FD_ZERO( &readfds ); FD_SET( iop_fd, &readfds ); // 1s sec read polling timeout struct timeval timeout; timeout.tv_sec = 1; timeout.tv_usec = 0; int rc = select( FD_SETSIZE, &readfds, NULL, NULL, &timeout ); // read from file when descriptor // indicates data available without blocking if ((rc > 0) && FD_ISSET(iop_fd, &readfds)) { // read into the appropriate offset within the rx_buf int temp = read(iop_fd, rx_buf + bytes_read, bytes_to_expect - bytes_read); if (!temp) { printf("EOF detected with %d bytes expected\n", bytes_to_expect - bytes_read); } else { bytes_read += temp; } } else if (rc < 0){ printf("%s: select on [%s], bytes_read[%d], errno=%d\n", __FUNCTION__, thread_args->device, bytes_read, errno); } else { printf("%s: select on [%s], bytes_read[%d], timeout\n", __FUNCTION__, thread_args->device, bytes_read); } } On Wed, Feb 3, 2010 at 9:03 AM, Mariusz Dec wrote: > > > 2010/2/3 Ravishankar N > >> Hello Michael, >> [..] >> >> But on a side note, read(byte[]) in turn calls the read() in a loop.In the >> native C function, the read is supposed to return a -1 upon timeout.But my >> driver >> does not support timeout.The default timeout value is zero and the linux >> select call upon zero time out causes an infinite wait.What am i >> missing...... >> >> > When I have tested RXTX between platforms, I have observed "hangup" inside > JNI driver when no data in Linux, is normal thing. > > Solution was setting the timeout for RXTX when no data from JNI driver. > > Something like that: > > commPort.enableReceiveTimeout(10); > > And it works perfect.... > > The only difference is that I am NOT using events - I am using continous > read in separate thread and if data is available, is parsed and transferred > to application using exception. > > Regards > Mariusz > > > >> Thanks and regards, >> Ravi >> >> Date: Wed, 3 Feb 2010 09:26:50 +0000 >> From: Michael Erskine >> To: "rxtx at qbang.org" >> Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? >> Message-ID: >> >> >> Content-Type: text/plain; charset="us-ascii" >> >> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >> Of >> > Ravishankar N >> > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? >> > >> > My serial port driver(apparently) does not support receive timeout.I >> > registered an event listener for DATA_AVAILABLE. However, the control >> never >> > seems to come out of the 'while' loop.Shouldn't the >> > InputStream.read return a '-1' immediately if no data is available (this >> seems >> > to be the default operation)? >> >> Your event handler should handle the event and return immediately so that >> its controlling thread can handle other events. I recommend a single read in >> the following manner: rawbuf is a byte[] of "reasonable" size and the >> read(byte[]) reads all available bytes up to the size of the buffer >> returning the number of bytes actually read... >> >> case SerialPortEvent.DATA_AVAILABLE: >> try { >> int i = is.read(rawbuf); >> if (i == -1) { >> << process EOF condition - should never happen >> >> return; >> } >> << process bytes (rawbuf, i); >> >> return; >> } catch (IOException e) { >> << promptly deal with exception >> >> return; >> } >> >> This style of reading has worked for me with RXTX on Linux and Windows XP >> for a good few years now in railway industry communications systems. Any >> timeouts (largely unnecessary in my applications) can be handled elsewhere, >> usually at a higher layer. >> >> Regards, >> Michael Erskine. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Feb 3 07:33:27 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:33:27 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: <73a89f361002030633j682610afia48dc7accd8e049b@mail.gmail.com> 2010/2/3 John Coffey > I'm guessing that this is driver specific. I recently had to support a > select()/poll() infrastructure for a linux serial DD, its certainly non > trivial to support async IO, so I suspect the problem in this case has to do > with missing poll infrastructure in the device driver. This also has to > coupled with special open flags for the device (which is within the rxtx > code) > > Yes, you are right, it may be driver specific, but in my case I haven't changed blocking JNI driver. I have added ONLY one call to RXTX method mentioned in my previous post and blocking (as seen as from Java app) gone out... Maybe this is not elegant, but works without problem in my app. I am using only FTDI chips and their drivers from couple of years and maybe this is the kind of the way to have no many problems with serial as well? Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From andyrxtx at g0poy.co.uk Wed Feb 3 11:09:04 2010 From: andyrxtx at g0poy.co.uk (andyrxtx at g0poy.co.uk) Date: Wed, 3 Feb 2010 18:09:04 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes Message-ID: <20100203180904.164f24dd@workstation.site> ?Hello RXTX group, I have just joined this group, and this is my first posting. I wanted to pass on some information regarding rxtx, so apologies if this has been brought up before. I have searched back through the archives but nothing specific came up. I am not a Java programmer, and I only came across rxtx a few days ago. I use a piece of test equipment called a miniVNA http://www.miniradiosolutions.com/ This is a serial USB controlled instrument, and it has control software available for MS windows, and a very old and now non-working Linux application. A few days ago Dietmar, DL2SBA released a Java application to control the miniVNA, obviously this application makes use of rxtx. The program worked fine on Windows, so I set about installing it onto Linux. I use SUSE11.1 After a few false starts, I got the system running fairly easily, sorting out the file locking by adding the uucp group to the users account as suggested (I used the 2.2pre binary files) I then passed the install instructions onto another miniVNA user, who also uses SUSE, but he ran into problems. To cut a long story short, he was also having file lock problems, but the uucp fix did not work. Digging into his system I found that there have been some changes in SUSE 11.2. tty ports are now assigned to the dialout group rather than uucp. A hint in the rxtx INSTALL file, suggested that var/lock needs to be checked, so: SUSE 11.1, var/lock is root:uucp SUSE 11.2 var/lock is root:root A search on Google brought up several comments regarding this, and also a bugzilla entry. https://bugzilla.novell.com/show_bug.cgi?id=552095 However from reading the various posts, some of which are in the bugzilla entry, it appears that many distros may be, or have changed to this configuration, and this will undoubtedly break several things, rxtx included. I solved my fellow SUSE users problem by compiling the rxtx libs with the no lock file option during configure, and that solved his problem. As this issue will probably take some time to get resolved across all the various Linux distros, it might be worth considering changing the default on the Linux build of rxtx not to use lockfiles, or provide the two versions of the lib in the binary archive. Thanks for your indulgence Andy From damorales at gmail.com Wed Feb 3 11:33:23 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 15:33:23 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203180904.164f24dd@workstation.site> References: <20100203180904.164f24dd@workstation.site> Message-ID: Hi I had the same problem in Mandriva 2010 and yes, adding the user to the uucp group did not work as it used to be in earlier versions of linux distros, causing RXTX to not work as non root user. The problem appears because the existense of UDEV, now you MUST add a RULE so the group (uucp or whatever) have access (Read, Write, Execute) to the Serial Port. To solve the problem, without needing to recompile RXTX, you must add a rule to grant permissions (0666) to the group for the device or port (tty*, ttyUSB*, etc). I do not remember now what is the line i added but when i come back home i will give it to you (i am at work now). Greetings ! 2010/2/3 > Hello RXTX group, > > I have just joined this group, and this is my first posting. > I wanted to pass on some information regarding rxtx, so apologies if > this has been brought up before. I have searched back through the > archives but nothing specific came up. > > I am not a Java programmer, and I only came across rxtx a few days ago. > > I use a piece of test equipment called a miniVNA > http://www.miniradiosolutions.com/ > > This is a serial USB controlled instrument, and it has control software > available for MS windows, and a very old and now non-working Linux > application. > > A few days ago Dietmar, DL2SBA released a Java application to control the > miniVNA, obviously this application makes use of rxtx. > > The program worked fine on Windows, so I set about installing it onto > Linux. I use SUSE11.1 After a few false starts, I got the system running > fairly easily, sorting out the file locking by adding the uucp group to > the users account as suggested (I used the 2.2pre binary files) I then > passed the install instructions onto another miniVNA user, who also uses > SUSE, but he ran into problems. To cut a long story short, he was > also having file lock problems, but the uucp fix did not work. Digging > into his system I found that there have been some changes in SUSE 11.2. > > tty ports are now assigned to the dialout group rather than uucp. > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > checked, so: > > SUSE 11.1, var/lock is root:uucp > SUSE 11.2 var/lock is root:root > > A search on Google brought up several comments regarding this, and also > a bugzilla entry. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > However from reading the various posts, some of which are in the bugzilla > entry, it appears that many distros may be, or have changed to this > configuration, and this will undoubtedly break several things, rxtx > included. > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > no lock file option during configure, and that solved his problem. > > As this issue will probably take some time to get resolved across all the > various Linux distros, it might be worth considering changing the default > on the Linux build of rxtx not to use lockfiles, or provide the two > versions of the lib in the binary archive. > > Thanks for your indulgence > > Andy > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Wed Feb 3 12:07:02 2010 From: andy at g0poy.com (Andy Eskelson) Date: Wed, 3 Feb 2010 19:07:02 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> Message-ID: <20100203190702.1b0e7015@workstation.site> Thanks Daniel, I am aware of the permissions problem, I have had a udev rules to solve this for other programs for some time. . I don't think that this is the same problem. as far as I can understand things, the lock files are written in var/lock. Previously var/lock and dev/tty-whatever were the same group. Now with var/lock owned by and with a group of root:root anything other than root cannot create a lock file. Even minicom is broken by this change. This change is going to have quite a few knock-on effects I think. Andy On Wed, 3 Feb 2010 15:33:23 -0300 Daniel Morales Salas wrote: > Hi > > I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > group did not work as it used to be in earlier versions of linux distros, > causing RXTX to not work as non root user. > > The problem appears because the existense of UDEV, now you MUST add a RULE > so the group (uucp or whatever) have access (Read, Write, Execute) to the > Serial Port. > > To solve the problem, without needing to recompile RXTX, you must add a rule > to grant permissions (0666) to the group for the device or port (tty*, > ttyUSB*, etc). I do not remember now what is the line i added but when i > come back home i will give it to you (i am at work now). > > Greetings ! > > 2010/2/3 > > > Hello RXTX group, > > > > I have just joined this group, and this is my first posting. > > I wanted to pass on some information regarding rxtx, so apologies if > > this has been brought up before. I have searched back through the > > archives but nothing specific came up. > > > > I am not a Java programmer, and I only came across rxtx a few days ago. > > > > I use a piece of test equipment called a miniVNA > > http://www.miniradiosolutions.com/ > > > > This is a serial USB controlled instrument, and it has control software > > available for MS windows, and a very old and now non-working Linux > > application. > > > > A few days ago Dietmar, DL2SBA released a Java application to control the > > miniVNA, obviously this application makes use of rxtx. > > > > The program worked fine on Windows, so I set about installing it onto > > Linux. I use SUSE11.1 After a few false starts, I got the system running > > fairly easily, sorting out the file locking by adding the uucp group to > > the users account as suggested (I used the 2.2pre binary files) I then > > passed the install instructions onto another miniVNA user, who also uses > > SUSE, but he ran into problems. To cut a long story short, he was > > also having file lock problems, but the uucp fix did not work. Digging > > into his system I found that there have been some changes in SUSE 11.2. > > > > tty ports are now assigned to the dialout group rather than uucp. > > > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > checked, so: > > > > SUSE 11.1, var/lock is root:uucp > > SUSE 11.2 var/lock is root:root > > > > A search on Google brought up several comments regarding this, and also > > a bugzilla entry. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > However from reading the various posts, some of which are in the bugzilla > > entry, it appears that many distros may be, or have changed to this > > configuration, and this will undoubtedly break several things, rxtx > > included. > > > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > > no lock file option during configure, and that solved his problem. > > > > As this issue will probably take some time to get resolved across all the > > various Linux distros, it might be worth considering changing the default > > on the Linux build of rxtx not to use lockfiles, or provide the two > > versions of the lib in the binary archive. > > > > Thanks for your indulgence > > > > Andy > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From thisdyingdream at gmail.com Wed Feb 3 12:32:35 2010 From: thisdyingdream at gmail.com (Steven Harms) Date: Wed, 3 Feb 2010 14:32:35 -0500 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203190702.1b0e7015@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: This is currently a bug in OpenSUSE that affects more than just rxtx, and is a result of unified udev rules. You can work around this by making udev change the group back to uucp until something more happens. https://bugzilla.novell.com/show_bug.cgi?id=552095 Thanks, Steve On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > Thanks Daniel, > > I am aware of the permissions problem, I have had a udev rules to solve > this for other programs for some time. > . > I don't think that this is the same problem. as far as I can understand > things, the lock files are written in var/lock. Previously var/lock and > dev/tty-whatever were the same group. Now with var/lock owned by and with > a group of root:root anything other than root cannot create a lock > file. Even minicom is broken by this change. > > This change is going to have quite a few knock-on effects I think. > > > Andy > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > Daniel Morales Salas wrote: > >> Hi >> >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp >> group did not work as it used to be in earlier versions of linux distros, >> causing RXTX to not work as non root user. >> >> The problem appears because the existense of UDEV, now you MUST add a RULE >> so the group (uucp or whatever) have access (Read, Write, Execute) to the >> Serial Port. >> >> To solve the problem, without needing to recompile RXTX, you must add a rule >> to grant permissions (0666) to the group for the device or port (tty*, >> ttyUSB*, etc). I do not remember now what is the line i added but when i >> come back home i will give it to you (i am at work now). >> >> Greetings ! >> >> 2010/2/3 >> >> > Hello RXTX group, >> > >> > I have just joined this group, and this is my first posting. >> > I wanted to pass on ?some information regarding rxtx, so apologies if >> > this has been brought up before. I have searched back through the >> > archives but nothing specific came up. >> > >> > I am not a Java programmer, and I only came across rxtx a few days ago. >> > >> > I use a piece of test equipment called a miniVNA >> > http://www.miniradiosolutions.com/ >> > >> > This is a serial USB controlled instrument, and it has control software >> > available for MS windows, and a very old and now non-working Linux >> > application. >> > >> > A few days ago Dietmar, DL2SBA released a Java application to control the >> > miniVNA, obviously this application makes use of rxtx. >> > >> > The program worked fine on Windows, so I set about installing it onto >> > Linux. I use SUSE11.1 After a few false starts, I got the system running >> > fairly easily, sorting out the file locking by adding the uucp group to >> > the users account as suggested (I used the 2.2pre binary files) I then >> > passed the install instructions onto another miniVNA user, who also uses >> > SUSE, but he ran into problems. To cut a long story short, he was >> > also having file lock problems, but the uucp fix did not work. Digging >> > into his system I found that there have been some changes in SUSE 11.2. >> > >> > tty ports are now assigned to the dialout group rather than uucp. >> > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be >> > checked, so: >> > >> > SUSE 11.1, var/lock is root:uucp >> > SUSE 11.2 var/lock is root:root >> > >> > A search on Google brought up several comments regarding this, and also >> > a ?bugzilla entry. >> > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 >> > >> > However from reading the various posts, some of which are in the bugzilla >> > entry, it appears that many distros may be, or have changed to this >> > configuration, and this will undoubtedly break several things, rxtx >> > included. >> > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the >> > no lock file option during configure, and that solved his problem. >> > >> > As this issue will probably take some time to get resolved across all the >> > various Linux distros, it might be worth considering changing the default >> > on the Linux build of rxtx not to use lockfiles, or provide the two >> > versions of the lib in the binary archive. >> > >> > Thanks for your indulgence >> > >> > Andy >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> >> >> >> -- >> Atte: >> Daniel Dario Morales Salas >> Ingeniero Civil en Computaci?n e Inform?tica >> Tel?fono: 02 684 3417 >> Celular: 09 643 1802 >> Santiago, Chile > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 WWW: http://www.sharms.org/blog From andy at g0poy.com Wed Feb 3 17:58:29 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 00:58:29 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: <20100204005829.7dc944e1@workstation.site> Thanks Steve, changing the serial ports back the uucp is not a big problem. I have a udev rule that can be easily modified already. However I cannot see any way of dealing with the var/lock problem apart from making it writable to all. Any thoughts? Andy On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms wrote: > This is currently a bug in OpenSUSE that affects more than just rxtx, > and is a result of unified udev rules. You can work around this by > making udev change the group back to uucp until something more > happens. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > Thanks, > > Steve > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > Thanks Daniel, > > > > I am aware of the permissions problem, I have had a udev rules to solve > > this for other programs for some time. > > . > > I don't think that this is the same problem. as far as I can understand > > things, the lock files are written in var/lock. Previously var/lock and > > dev/tty-whatever were the same group. Now with var/lock owned by and with > > a group of root:root anything other than root cannot create a lock > > file. Even minicom is broken by this change. > > > > This change is going to have quite a few knock-on effects I think. > > > > > > Andy > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > Daniel Morales Salas wrote: > > > >> Hi > >> > >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > >> group did not work as it used to be in earlier versions of linux distros, > >> causing RXTX to not work as non root user. > >> > >> The problem appears because the existense of UDEV, now you MUST add a RULE > >> so the group (uucp or whatever) have access (Read, Write, Execute) to the > >> Serial Port. > >> > >> To solve the problem, without needing to recompile RXTX, you must add a rule > >> to grant permissions (0666) to the group for the device or port (tty*, > >> ttyUSB*, etc). I do not remember now what is the line i added but when i > >> come back home i will give it to you (i am at work now). > >> > >> Greetings ! > >> > >> 2010/2/3 > >> > >> > Hello RXTX group, > >> > > >> > I have just joined this group, and this is my first posting. > >> > I wanted to pass on ?some information regarding rxtx, so apologies if > >> > this has been brought up before. I have searched back through the > >> > archives but nothing specific came up. > >> > > >> > I am not a Java programmer, and I only came across rxtx a few days ago. > >> > > >> > I use a piece of test equipment called a miniVNA > >> > http://www.miniradiosolutions.com/ > >> > > >> > This is a serial USB controlled instrument, and it has control software > >> > available for MS windows, and a very old and now non-working Linux > >> > application. > >> > > >> > A few days ago Dietmar, DL2SBA released a Java application to control the > >> > miniVNA, obviously this application makes use of rxtx. > >> > > >> > The program worked fine on Windows, so I set about installing it onto > >> > Linux. I use SUSE11.1 After a few false starts, I got the system running > >> > fairly easily, sorting out the file locking by adding the uucp group to > >> > the users account as suggested (I used the 2.2pre binary files) I then > >> > passed the install instructions onto another miniVNA user, who also uses > >> > SUSE, but he ran into problems. To cut a long story short, he was > >> > also having file lock problems, but the uucp fix did not work. Digging > >> > into his system I found that there have been some changes in SUSE 11.2. > >> > > >> > tty ports are now assigned to the dialout group rather than uucp. > >> > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > >> > checked, so: > >> > > >> > SUSE 11.1, var/lock is root:uucp > >> > SUSE 11.2 var/lock is root:root > >> > > >> > A search on Google brought up several comments regarding this, and also > >> > a ?bugzilla entry. > >> > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > >> > > >> > However from reading the various posts, some of which are in the bugzilla > >> > entry, it appears that many distros may be, or have changed to this > >> > configuration, and this will undoubtedly break several things, rxtx > >> > included. > >> > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the > >> > no lock file option during configure, and that solved his problem. > >> > > >> > As this issue will probably take some time to get resolved across all the > >> > various Linux distros, it might be worth considering changing the default > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > >> > versions of the lib in the binary archive. > >> > > >> > Thanks for your indulgence > >> > > >> > Andy > >> > > >> > _______________________________________________ > >> > Rxtx mailing list > >> > Rxtx at qbang.org > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > >> > >> > >> > >> -- > >> Atte: > >> Daniel Dario Morales Salas > >> Ingeniero Civil en Computaci?n e Inform?tica > >> Tel?fono: 02 684 3417 > >> Celular: 09 643 1802 > >> Santiago, Chile > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > WWW: http://www.sharms.org/blog From damorales at gmail.com Wed Feb 3 18:26:38 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 22:26:38 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100204005829.7dc944e1@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: Hello I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva 2010 this is what i get: drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ and i don't have ANY problem with lock files and RXTX in my java software. All i had to do was add this rule to udev: # serial KERNEL=="tty*", GROUP="uucp", MODE="0666" and that was all. Of course my user (metalklesk) is part of uucp group. I did not make /var/lock writable to all users. Greetings ! 2010/2/3 Andy Eskelson > Thanks Steve, > > changing the serial ports back the uucp is not a big problem. I have a > udev rule that can be easily modified already. However I cannot see any > way of dealing with the var/lock problem apart from making it writable to > all. Any thoughts? > > Andy > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > wrote: > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > and is a result of unified udev rules. You can work around this by > > making udev change the group back to uucp until something more > > happens. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > Thanks, > > > > Steve > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > Thanks Daniel, > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > this for other programs for some time. > > > . > > > I don't think that this is the same problem. as far as I can understand > > > things, the lock files are written in var/lock. Previously var/lock and > > > dev/tty-whatever were the same group. Now with var/lock owned by and > with > > > a group of root:root anything other than root cannot create a lock > > > file. Even minicom is broken by this change. > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > Daniel Morales Salas wrote: > > > > > >> Hi > > >> > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > the uucp > > >> group did not work as it used to be in earlier versions of linux > distros, > > >> causing RXTX to not work as non root user. > > >> > > >> The problem appears because the existense of UDEV, now you MUST add a > RULE > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > the > > >> Serial Port. > > >> > > >> To solve the problem, without needing to recompile RXTX, you must add > a rule > > >> to grant permissions (0666) to the group for the device or port (tty*, > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > i > > >> come back home i will give it to you (i am at work now). > > >> > > >> Greetings ! > > >> > > >> 2010/2/3 > > >> > > >> > Hello RXTX group, > > >> > > > >> > I have just joined this group, and this is my first posting. > > >> > I wanted to pass on some information regarding rxtx, so apologies > if > > >> > this has been brought up before. I have searched back through the > > >> > archives but nothing specific came up. > > >> > > > >> > I am not a Java programmer, and I only came across rxtx a few days > ago. > > >> > > > >> > I use a piece of test equipment called a miniVNA > > >> > http://www.miniradiosolutions.com/ > > >> > > > >> > This is a serial USB controlled instrument, and it has control > software > > >> > available for MS windows, and a very old and now non-working Linux > > >> > application. > > >> > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > control the > > >> > miniVNA, obviously this application makes use of rxtx. > > >> > > > >> > The program worked fine on Windows, so I set about installing it > onto > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > running > > >> > fairly easily, sorting out the file locking by adding the uucp group > to > > >> > the users account as suggested (I used the 2.2pre binary files) I > then > > >> > passed the install instructions onto another miniVNA user, who also > uses > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > >> > also having file lock problems, but the uucp fix did not work. > Digging > > >> > into his system I found that there have been some changes in SUSE > 11.2. > > >> > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > >> > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > >> > checked, so: > > >> > > > >> > SUSE 11.1, var/lock is root:uucp > > >> > SUSE 11.2 var/lock is root:root > > >> > > > >> > A search on Google brought up several comments regarding this, and > also > > >> > a bugzilla entry. > > >> > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > >> > > > >> > However from reading the various posts, some of which are in the > bugzilla > > >> > entry, it appears that many distros may be, or have changed to this > > >> > configuration, and this will undoubtedly break several things, rxtx > > >> > included. > > >> > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > with the > > >> > no lock file option during configure, and that solved his problem. > > >> > > > >> > As this issue will probably take some time to get resolved across > all the > > >> > various Linux distros, it might be worth considering changing the > default > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > >> > versions of the lib in the binary archive. > > >> > > > >> > Thanks for your indulgence > > >> > > > >> > Andy > > >> > > > >> > _______________________________________________ > > >> > Rxtx mailing list > > >> > Rxtx at qbang.org > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > >> > > > >> > > >> > > >> > > >> -- > > >> Atte: > > >> Daniel Dario Morales Salas > > >> Ingeniero Civil en Computaci?n e Inform?tica > > >> Tel?fono: 02 684 3417 > > >> Celular: 09 643 1802 > > >> Santiago, Chile > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at qbang.org > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > -- > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > WWW: http://www.sharms.org/blog > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Thu Feb 4 05:31:46 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 12:31:46 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: <20100204123146.6cffeb67@workstation.site> Thank's for the confirmation. Something odd is going on somewhere in SUSE 11.2. I'll have to build up a local SUSE11.2 system to see if I can nail down exactly what is going on. Something is blocking the lockfiles in var/lock. The net is nice, but it's a bit difficult trying to work out what is going on what the machine in question is in Germany and I'm in the UK :-) Andy On Wed, 3 Feb 2010 22:26:38 -0300 Daniel Morales Salas wrote: > Hello > > I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva > 2010 this is what i get: > > drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ > > and i don't have ANY problem with lock files and RXTX in my java software. > All i had to do was add this rule to udev: > > # serial > KERNEL=="tty*", GROUP="uucp", MODE="0666" > > and that was all. Of course my user (metalklesk) is part of uucp group. > I did not make /var/lock writable to all users. > > Greetings ! > > 2010/2/3 Andy Eskelson > > > Thanks Steve, > > > > changing the serial ports back the uucp is not a big problem. I have a > > udev rule that can be easily modified already. However I cannot see any > > way of dealing with the var/lock problem apart from making it writable to > > all. Any thoughts? > > > > Andy > > > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > > wrote: > > > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > > and is a result of unified udev rules. You can work around this by > > > making udev change the group back to uucp until something more > > > happens. > > > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > > > Thanks, > > > > > > Steve > > > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > > Thanks Daniel, > > > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > > this for other programs for some time. > > > > . > > > > I don't think that this is the same problem. as far as I can understand > > > > things, the lock files are written in var/lock. Previously var/lock and > > > > dev/tty-whatever were the same group. Now with var/lock owned by and > > with > > > > a group of root:root anything other than root cannot create a lock > > > > file. Even minicom is broken by this change. > > > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > > Daniel Morales Salas wrote: > > > > > > > >> Hi > > > >> > > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > > the uucp > > > >> group did not work as it used to be in earlier versions of linux > > distros, > > > >> causing RXTX to not work as non root user. > > > >> > > > >> The problem appears because the existense of UDEV, now you MUST add a > > RULE > > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > > the > > > >> Serial Port. > > > >> > > > >> To solve the problem, without needing to recompile RXTX, you must add > > a rule > > > >> to grant permissions (0666) to the group for the device or port (tty*, > > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > > i > > > >> come back home i will give it to you (i am at work now). > > > >> > > > >> Greetings ! > > > >> > > > >> 2010/2/3 > > > >> > > > >> > Hello RXTX group, > > > >> > > > > >> > I have just joined this group, and this is my first posting. > > > >> > I wanted to pass on some information regarding rxtx, so apologies > > if > > > >> > this has been brought up before. I have searched back through the > > > >> > archives but nothing specific came up. > > > >> > > > > >> > I am not a Java programmer, and I only came across rxtx a few days > > ago. > > > >> > > > > >> > I use a piece of test equipment called a miniVNA > > > >> > http://www.miniradiosolutions.com/ > > > >> > > > > >> > This is a serial USB controlled instrument, and it has control > > software > > > >> > available for MS windows, and a very old and now non-working Linux > > > >> > application. > > > >> > > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > > control the > > > >> > miniVNA, obviously this application makes use of rxtx. > > > >> > > > > >> > The program worked fine on Windows, so I set about installing it > > onto > > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > > running > > > >> > fairly easily, sorting out the file locking by adding the uucp group > > to > > > >> > the users account as suggested (I used the 2.2pre binary files) I > > then > > > >> > passed the install instructions onto another miniVNA user, who also > > uses > > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > > >> > also having file lock problems, but the uucp fix did not work. > > Digging > > > >> > into his system I found that there have been some changes in SUSE > > 11.2. > > > >> > > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > > >> > > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > > >> > checked, so: > > > >> > > > > >> > SUSE 11.1, var/lock is root:uucp > > > >> > SUSE 11.2 var/lock is root:root > > > >> > > > > >> > A search on Google brought up several comments regarding this, and > > also > > > >> > a bugzilla entry. > > > >> > > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > >> > > > > >> > However from reading the various posts, some of which are in the > > bugzilla > > > >> > entry, it appears that many distros may be, or have changed to this > > > >> > configuration, and this will undoubtedly break several things, rxtx > > > >> > included. > > > >> > > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > > with the > > > >> > no lock file option during configure, and that solved his problem. > > > >> > > > > >> > As this issue will probably take some time to get resolved across > > all the > > > >> > various Linux distros, it might be worth considering changing the > > default > > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > > >> > versions of the lib in the binary archive. > > > >> > > > > >> > Thanks for your indulgence > > > >> > > > > >> > Andy > > > >> > > > > >> > _______________________________________________ > > > >> > Rxtx mailing list > > > >> > Rxtx at qbang.org > > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > > >> > > > > >> > > > >> > > > >> > > > >> -- > > > >> Atte: > > > >> Daniel Dario Morales Salas > > > >> Ingeniero Civil en Computaci?n e Inform?tica > > > >> Tel?fono: 02 684 3417 > > > >> Celular: 09 643 1802 > > > >> Santiago, Chile > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at qbang.org > > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > > > -- > > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > > > WWW: http://www.sharms.org/blog > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From Bob_Jacobsen at lbl.gov Thu Feb 4 09:26:49 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Thu, 4 Feb 2010 08:26:49 -0800 Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 Message-ID: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're using RXTX-2.2pre2, although it emits the known message about "Version mismatch". WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 After the usual messing around, we've got it working on 11 Windows versions, multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ have things working rarely say so, so I don't know whether anybody has gotten it to work on 10.4 or not. The problem encountered is this: dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib dyld: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib followed by the JVM crashing hard. I've got those dump files if that would help. Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If so, is there a patch I can get and build? Thanks Bob -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From tjarvi at qbang.org Thu Feb 4 14:22:21 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 4 Feb 2010 14:22:21 -0700 (MST) Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 In-Reply-To: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> References: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> Message-ID: On Thu, 4 Feb 2010, Bob Jacobsen wrote: > We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're > using RXTX-2.2pre2, although it emits the known message about "Version > mismatch". > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > > After the usual messing around, we've got it working on 11 Windows versions, > multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with > a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ > have things working rarely say so, so I don't know whether anybody has gotten > it to work on 10.4 or not. > > The problem encountered is this: > > dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > dyld: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > followed by the JVM crashing hard. I've got those dump files if that would > help. > > Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If > so, is there a patch I can get and build? > Hi Bob, I talked to a coworker about the problem you ran into. It appears that it is possible to target 'older' Mac systems through makefile configuration changes. "Configuring a Makefile-Based Project If you have a makefile-based project, you can also take advantage of SDK-based development, by adding the appropriate options to your compile and link commands. Using SDKs in makefile-based projects requires GCC 4.0 or later. To choose an SDK, you use the -isysroot option with the compiler and the -syslibroot option with the linker. Both options require that you specify the full path to the desired SDK directory. To set the Deployment OS version in a makefile, use a makefile variable of the form: ENVP= MACOSX_DEPLOYMENT_TARGET=10.4. To use this variable in your makefile, include it in front of your compile and link commands." http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html Or build on the oldest system you want to support. -- Trent Jarvi tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Thu Feb 4 14:56:19 2010 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Thu, 4 Feb 2010 14:56:19 -0700 Subject: [Rxtx] RXTX on 64 Bit Redhat In-Reply-To: References: <4ec9eab61001281448g3dd84910r867619948a4e0d7a@mail.gmail.com> Message-ID: Trent -- Finally fixed all my build related issues. I ran into another issue. On one of my machines my JDK is returning multiple folders for the "java.ext.dirs" (java.ext.dirs -> /opt/jdk1.6.0_17/jre/lib/ext:/usr/java/packages/lib/ext) system property. As a result my JVM wasn't able to detect the gnu.io.rxtx.properties. I am attaching a patch for RXTXCommDriver.java file to check for multiple locations. Also i have to assign permission 660 to all my dev ports to be located by RXTX. Pawan ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 5:12 PM To: Trent Jarvi Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Here is the error i get when i build the src from release-2-1-7 -bash-3.2$ make ( \ \ cd i686-pc-linux-gnu; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/ jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I/opt/jav a1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec - c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialImp.lo;\ if [ "Serial" = "Serial" ]; then \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I /opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_tim espec -c /home/jb_stg/rxtx/rxtx-devel/./src/fuserImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ else \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo; \ fi; \ ) gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/inclu de -I/opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need _timespec -c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -fPIC -DPIC -o /hom e/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/.libs/SerialImp.o /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:25:29: error: gnu_io_RXTXPort.h: No such file or directory In file included from /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:113: /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:91: error: expected specifier-qua lifier-list before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'jobject' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:408: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:409: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:410: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:411: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:415: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:416: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:417: error: expected '=', ',', '; ', 'asm' or '__attribute__' before 'is_interrupted' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:418: error: expected declaration specifiers or '...' before 'jint' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:424: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:441: error: expected ')' before ' *' token ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 4:57 PM To: Santosh Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Santosh -- Thank you. That fixed the issue. All -- What CVS branch or release should i use to get the latest RXTX src code. Pawan ________________________________ From: Santosh [mailto:santosh.ry at gmail.com] Sent: Thursday, January 28, 2010 3:49 PM To: Kharbanda, Pawan Cc: Trent Jarvi; rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat error "./configure: /bin/sh^M: bad interpreter: No such file or directory". I think you need to run dos2unix on script files before compiling. Thanks, Santosh On Thu, Jan 28, 2010 at 5:33 PM, Kharbanda, Pawan > wrote: Trent -- We are upgrading our exisiting OS and JDK on a project that rely heavily on RXTX api's. We are now using JDK1.6 32 bit (build 1.6.0_17-b04) and RedHat 5 on a 64 bit machine. Linux tocrhstg02.dot.state.co.us 2.6.18-164.6.1.el5 #1 SMP Tue Oct 27 11:30:06 EDT 2009 i686 i686 i386 GNU/Linux Red Hat Enterprise Linux Server release 5.4 (Tikanga) I tried to run version 2.1.7 r2 on it but not able to see any of my Digi ports I was able to access only /dev/ttyS0 (physical ports). Not sure if the problem is with the Digi driver or RXTX. I tried to open a Digi port with minicom and it worked fine. I also tried to get latest from CVS (rxtx-devel) and when I do "configure" I see this error "./configure: /bin/sh^M: bad interpreter: No such file or directory". Can someone please help me with this? Thanks for the help. Pawan _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch.txt URL: From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 01:02:21 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 13:32:21 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> My serial port driver(apparently) does not support receive timeout.I registered an event listener for DATA_AVAILABLE. However, the control never seems to come out of the 'while' loop.Shouldn't the InputStream.read return a '-1' immediately if no data is available (this seems to be the default operation)? This was tried on a x86 Linux desktop using rxtx-2.1-7 I've added the snippet for clarity: /******************************************************************************************************************************************************************************/ mySerialPort.enableReceiveThreshold(2000);//Trying to set a time limit for read calls System.out.println(mySerialPort.isReceiveTimeoutEnabled()); // I get FALSE, so its not supported on hardware. mySerialPort.addEventListener(this); mySerialPort.notifyOnDataAvailable(true);//register a event with //my SerialEvent listener implementation: public void serialEvent(SerialPortEvent arg0) { int newData=0; switch(arg0.getEventType()){ case SerialPortEvent.DATA_AVAILABLE: while (newData != -1) { try { newData = is.read();//This should eventually return a -1 if no data is available within a timeout.PROBLEM!! System.out.println("Got a byte from port:"+newData); if (newData == -1) { break; } } catch (IOException ex) { System.err.println(ex); return; } } break; } return; } /******************************************************************************************************************************************************************************/ Thanks and regards, Ravi From michael.erskine at ketech.com Wed Feb 3 02:26:50 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 09:26:50 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From michael.erskine at ketech.com Wed Feb 3 05:03:30 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 12:03:30 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > Michael Erskine > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > > Your event handler should handle the event and return immediately so that its > controlling thread can handle other events. I recommend a single read in the > following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) > reads all available bytes up to the size of the buffer returning the number of > bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } After posting this I considered the glaring possibility of the rawbuf read buffer being too small to receive all the available bytes and perhaps skipping data: after all, I'm guessing that is why we see so many posts asking for help with blocking implementations of read event handlers looping on "while(bytes are available)". I've spent this morning writing an extensive multi-threaded unit test suite that includes tests with a tiny buffer compared to the amount of data available and found that no data was being skipped. I now want to know why! The SerialPortEvent.DATA_AVAILABLE event must be being fired again if there is more data available on the input stream. If that is the case then it should be heavily documented with good examples in the wiki to avoid the types of developer anguish we see so regularly. BTW: I'm not at liberty to post the JUnit tests as they use my company's unit test suite framework. Regards, Michael Erskine. From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 06:18:04 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 18:48:04 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Hello Michael, I tried out your suggestion but the problem is that the read(rawbuf) blocks until the entire length of the rawbuf array has been read (blocking). I cannot decide on a reasonable size of the array because it varies from 2 bytes to as much as 50 byes (i'm communicating with a modem,each response is of a different length), which is why i wanted to use non blocking calls. But on a side note, read(byte[]) in turn calls the read() in a loop.In the native C function, the read is supposed to return a -1 upon timeout.But my driver does not support timeout.The default timeout value is zero and the linux select call upon zero time out causes an infinite wait.What am i missing...... Thanks and regards, Ravi Date: Wed, 3 Feb 2010 09:26:50 +0000 From: Michael Erskine To: "rxtx at qbang.org" Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: Content-Type: text/plain; charset="us-ascii" > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From m.kirkland at comcast.net Wed Feb 3 06:46:03 2010 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 3 Feb 2010 05:46:03 -0800 Subject: [Rxtx] One port blocking another port In-Reply-To: References: Message-ID: <68768633814F4D7D86761D34F0764FE0@bengal.net> It turns out this is caused by having the RTS/CTS flow control turned on and me not providing a true on the RTS pin. Somehow it seems the port timing out on a read allows the write to proceed. This is not an issue for my application but I wonder if the write should not proceed until the RTS pin is true even if a read times out. mk -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Monday, January 25, 2010 7:48 PM To: Mike Kirkland Cc: rxtx at qbang.org Subject: Re: [Rxtx] One port blocking another port On Mon, 25 Jan 2010, Mike Kirkland wrote: > > Hi All, > > ? > > I have a program that reads from one com port and writes to another com > port. It also does the same thing in reverse (reads from the second com port > and writes to the first one. It basically ties two com ports together. > > ? > > One port is very chatty and has a consent stream of data. The other port has > very little data. > > ? > > Both ports use a 5000 ms (5 second) time out. > > ? > > The issue I am having is that is appears that the first port?s write to the > second port is blocked while the second port is waiting for input. The first > port?s write proceeds only after the second port has timed out. > > ? > > I suppose I could have something twisted around in my code but I was > wondering if this is a know issue? > Hi Kirk, I've not seen a report like this. Perhaps some simple reproduction code will reveal a problem on your end or help us identify a problem in rxtx. I think there are several users doing multiport communication. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Wed Feb 3 07:03:58 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:03:58 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Message-ID: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> 2010/2/3 Ravishankar N > Hello Michael, > [..] > But on a side note, read(byte[]) in turn calls the read() in a loop.In the > native C function, the read is supposed to return a -1 upon timeout.But my > driver > does not support timeout.The default timeout value is zero and the linux > select call upon zero time out causes an infinite wait.What am i > missing...... > > When I have tested RXTX between platforms, I have observed "hangup" inside JNI driver when no data in Linux, is normal thing. Solution was setting the timeout for RXTX when no data from JNI driver. Something like that: commPort.enableReceiveTimeout(10); And it works perfect.... The only difference is that I am NOT using events - I am using continous read in separate thread and if data is available, is parsed and transferred to application using exception. Regards Mariusz > Thanks and regards, > Ravi > > Date: Wed, 3 Feb 2010 09:26:50 +0000 > From: Michael Erskine > To: "rxtx at qbang.org" > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > Message-ID: > > > Content-Type: text/plain; charset="us-ascii" > > > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of > > Ravishankar N > > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > > > My serial port driver(apparently) does not support receive timeout.I > > registered an event listener for DATA_AVAILABLE. However, the control > never > > seems to come out of the 'while' loop.Shouldn't the > > InputStream.read return a '-1' immediately if no data is available (this > seems > > to be the default operation)? > > Your event handler should handle the event and return immediately so that > its controlling thread can handle other events. I recommend a single read in > the following manner: rawbuf is a byte[] of "reasonable" size and the > read(byte[]) reads all available bytes up to the size of the buffer > returning the number of bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } > > This style of reading has worked for me with RXTX on Linux and Windows XP > for a good few years now in railway industry communications systems. Any > timeouts (largely unnecessary in my applications) can be handled elsewhere, > usually at a higher layer. > > Regards, > Michael Erskine. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Feb 3 07:22:55 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 3 Feb 2010 09:22:55 -0500 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: I'm guessing that this is driver specific. I recently had to support a select()/poll() infrastructure for a linux serial DD, its certainly non trivial to support async IO, so I suspect the problem in this case has to do with missing poll infrastructure in the device driver. This also has to coupled with special open flags for the device (which is within the rxtx code) The key routines within a 2.6 kernel linux device driver are shown below (if you have access to it for your particular device) are indicated below (here is a snippet from my device driver c code that supports polling/select). User space code to test this shown below also, note that the device needs to be opened with the O_NONBLOCK option to support the select/poll api // device driver code ..... /* * File operations supported by this driver. */ static struct file_operations iop_fops = { .owner = THIS_MODULE, .check_flags= iop_check_flags, .ioctl = iop_ioctl, .open = iop_open, .poll = iop_poll, // SUPPORT FOR SELECT/POLL infrastructure .read = iop_read, .release = iop_release, .write = iop_write, }; /** * Select/poll/epoll infrastructure. * * @param file * @param wait * * @return */ static unsigned int iop_poll(struct file *filp, poll_table *wait) { struct iop_device *devp = (struct iop_device *)filp->private_data; // the poll_table wait arg is an opaque pointer poll_wait(filp, &devp->readq, wait); // return from poll indicating whether we have read/write data unsigned int mask = 0; if (kfifo_len(devp->rx_fifo)) { mask |= (POLLIN | POLLRDNORM); } // @JC We don't do select on write yet // if (kfifo_len(devp->tx_fifo)) { // mask |= (POLLOUT | POLLWRNORM); // } // Only print out while debugging // if (mask != 0) { // printk (KERN_INFO "%s: [%04x]\n", __FUNCTION__, mask); // } return mask; } /** * device driver blocking and non blocking read function. This * function reads the requested number of bytes from the read * kfifo blocking as required. * * @param filp * @param buf * @param count * @param f_pos * * @return */ static ssize_t iop_read(struct file *filp, char __user *buf, size_t count, loff_t * ppos) { // access appropriate device struct struct iop_device *devp = (struct iop_device *) filp->private_data; ssize_t retval; // support non blocking mode (default) by checking if the kfifo is empty first if ((kfifo_len(devp->rx_fifo)==0) && (filp->f_flags & O_NONBLOCK)) { return -EAGAIN; } // wait for rx_fifo to receive data via receive interrupts retval = wait_event_interruptible(devp->readq, kfifo_len(devp->rx_fifo) != 0); // check for some error condition if (retval) { printk (KERN_ERR "%s: wait_event_interruptible returned[%d]\n", __FUNCTION__, retval); return retval; } // copy max requested bytes from rx_fifo to device buffer // this may still leave bytes in the kfifo for a subsequent read // if we are reading in a loop retval = kfifo_get(devp->rx_fifo, devp->rxbuf, count); // printk (KERN_INFO "%s: [%d] byte(s)\n", __FUNCTION__, retval); if (copy_to_user(buf, devp->rxbuf, retval)) { printk (KERN_ERR "%s: problem copying rx_fifo data to user buffer\n", __FUNCTION__); return -EFAULT; } return retval; } // a selection of my user space code reading via select()/poll()..... // user space open code iop_fd = ::open( deviceName.data(), O_RDWR | O_NONBLOCK); while ((bytes_to_expect - bytes_read) > 0) { // must reinitialize these between select calls fd_set readfds; FD_ZERO( &readfds ); FD_SET( iop_fd, &readfds ); // 1s sec read polling timeout struct timeval timeout; timeout.tv_sec = 1; timeout.tv_usec = 0; int rc = select( FD_SETSIZE, &readfds, NULL, NULL, &timeout ); // read from file when descriptor // indicates data available without blocking if ((rc > 0) && FD_ISSET(iop_fd, &readfds)) { // read into the appropriate offset within the rx_buf int temp = read(iop_fd, rx_buf + bytes_read, bytes_to_expect - bytes_read); if (!temp) { printf("EOF detected with %d bytes expected\n", bytes_to_expect - bytes_read); } else { bytes_read += temp; } } else if (rc < 0){ printf("%s: select on [%s], bytes_read[%d], errno=%d\n", __FUNCTION__, thread_args->device, bytes_read, errno); } else { printf("%s: select on [%s], bytes_read[%d], timeout\n", __FUNCTION__, thread_args->device, bytes_read); } } On Wed, Feb 3, 2010 at 9:03 AM, Mariusz Dec wrote: > > > 2010/2/3 Ravishankar N > >> Hello Michael, >> [..] >> >> But on a side note, read(byte[]) in turn calls the read() in a loop.In the >> native C function, the read is supposed to return a -1 upon timeout.But my >> driver >> does not support timeout.The default timeout value is zero and the linux >> select call upon zero time out causes an infinite wait.What am i >> missing...... >> >> > When I have tested RXTX between platforms, I have observed "hangup" inside > JNI driver when no data in Linux, is normal thing. > > Solution was setting the timeout for RXTX when no data from JNI driver. > > Something like that: > > commPort.enableReceiveTimeout(10); > > And it works perfect.... > > The only difference is that I am NOT using events - I am using continous > read in separate thread and if data is available, is parsed and transferred > to application using exception. > > Regards > Mariusz > > > >> Thanks and regards, >> Ravi >> >> Date: Wed, 3 Feb 2010 09:26:50 +0000 >> From: Michael Erskine >> To: "rxtx at qbang.org" >> Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? >> Message-ID: >> >> >> Content-Type: text/plain; charset="us-ascii" >> >> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >> Of >> > Ravishankar N >> > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? >> > >> > My serial port driver(apparently) does not support receive timeout.I >> > registered an event listener for DATA_AVAILABLE. However, the control >> never >> > seems to come out of the 'while' loop.Shouldn't the >> > InputStream.read return a '-1' immediately if no data is available (this >> seems >> > to be the default operation)? >> >> Your event handler should handle the event and return immediately so that >> its controlling thread can handle other events. I recommend a single read in >> the following manner: rawbuf is a byte[] of "reasonable" size and the >> read(byte[]) reads all available bytes up to the size of the buffer >> returning the number of bytes actually read... >> >> case SerialPortEvent.DATA_AVAILABLE: >> try { >> int i = is.read(rawbuf); >> if (i == -1) { >> << process EOF condition - should never happen >> >> return; >> } >> << process bytes (rawbuf, i); >> >> return; >> } catch (IOException e) { >> << promptly deal with exception >> >> return; >> } >> >> This style of reading has worked for me with RXTX on Linux and Windows XP >> for a good few years now in railway industry communications systems. Any >> timeouts (largely unnecessary in my applications) can be handled elsewhere, >> usually at a higher layer. >> >> Regards, >> Michael Erskine. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Feb 3 07:33:27 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:33:27 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: <73a89f361002030633j682610afia48dc7accd8e049b@mail.gmail.com> 2010/2/3 John Coffey > I'm guessing that this is driver specific. I recently had to support a > select()/poll() infrastructure for a linux serial DD, its certainly non > trivial to support async IO, so I suspect the problem in this case has to do > with missing poll infrastructure in the device driver. This also has to > coupled with special open flags for the device (which is within the rxtx > code) > > Yes, you are right, it may be driver specific, but in my case I haven't changed blocking JNI driver. I have added ONLY one call to RXTX method mentioned in my previous post and blocking (as seen as from Java app) gone out... Maybe this is not elegant, but works without problem in my app. I am using only FTDI chips and their drivers from couple of years and maybe this is the kind of the way to have no many problems with serial as well? Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From andyrxtx at g0poy.co.uk Wed Feb 3 11:09:04 2010 From: andyrxtx at g0poy.co.uk (andyrxtx at g0poy.co.uk) Date: Wed, 3 Feb 2010 18:09:04 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes Message-ID: <20100203180904.164f24dd@workstation.site> ?Hello RXTX group, I have just joined this group, and this is my first posting. I wanted to pass on some information regarding rxtx, so apologies if this has been brought up before. I have searched back through the archives but nothing specific came up. I am not a Java programmer, and I only came across rxtx a few days ago. I use a piece of test equipment called a miniVNA http://www.miniradiosolutions.com/ This is a serial USB controlled instrument, and it has control software available for MS windows, and a very old and now non-working Linux application. A few days ago Dietmar, DL2SBA released a Java application to control the miniVNA, obviously this application makes use of rxtx. The program worked fine on Windows, so I set about installing it onto Linux. I use SUSE11.1 After a few false starts, I got the system running fairly easily, sorting out the file locking by adding the uucp group to the users account as suggested (I used the 2.2pre binary files) I then passed the install instructions onto another miniVNA user, who also uses SUSE, but he ran into problems. To cut a long story short, he was also having file lock problems, but the uucp fix did not work. Digging into his system I found that there have been some changes in SUSE 11.2. tty ports are now assigned to the dialout group rather than uucp. A hint in the rxtx INSTALL file, suggested that var/lock needs to be checked, so: SUSE 11.1, var/lock is root:uucp SUSE 11.2 var/lock is root:root A search on Google brought up several comments regarding this, and also a bugzilla entry. https://bugzilla.novell.com/show_bug.cgi?id=552095 However from reading the various posts, some of which are in the bugzilla entry, it appears that many distros may be, or have changed to this configuration, and this will undoubtedly break several things, rxtx included. I solved my fellow SUSE users problem by compiling the rxtx libs with the no lock file option during configure, and that solved his problem. As this issue will probably take some time to get resolved across all the various Linux distros, it might be worth considering changing the default on the Linux build of rxtx not to use lockfiles, or provide the two versions of the lib in the binary archive. Thanks for your indulgence Andy From damorales at gmail.com Wed Feb 3 11:33:23 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 15:33:23 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203180904.164f24dd@workstation.site> References: <20100203180904.164f24dd@workstation.site> Message-ID: Hi I had the same problem in Mandriva 2010 and yes, adding the user to the uucp group did not work as it used to be in earlier versions of linux distros, causing RXTX to not work as non root user. The problem appears because the existense of UDEV, now you MUST add a RULE so the group (uucp or whatever) have access (Read, Write, Execute) to the Serial Port. To solve the problem, without needing to recompile RXTX, you must add a rule to grant permissions (0666) to the group for the device or port (tty*, ttyUSB*, etc). I do not remember now what is the line i added but when i come back home i will give it to you (i am at work now). Greetings ! 2010/2/3 > Hello RXTX group, > > I have just joined this group, and this is my first posting. > I wanted to pass on some information regarding rxtx, so apologies if > this has been brought up before. I have searched back through the > archives but nothing specific came up. > > I am not a Java programmer, and I only came across rxtx a few days ago. > > I use a piece of test equipment called a miniVNA > http://www.miniradiosolutions.com/ > > This is a serial USB controlled instrument, and it has control software > available for MS windows, and a very old and now non-working Linux > application. > > A few days ago Dietmar, DL2SBA released a Java application to control the > miniVNA, obviously this application makes use of rxtx. > > The program worked fine on Windows, so I set about installing it onto > Linux. I use SUSE11.1 After a few false starts, I got the system running > fairly easily, sorting out the file locking by adding the uucp group to > the users account as suggested (I used the 2.2pre binary files) I then > passed the install instructions onto another miniVNA user, who also uses > SUSE, but he ran into problems. To cut a long story short, he was > also having file lock problems, but the uucp fix did not work. Digging > into his system I found that there have been some changes in SUSE 11.2. > > tty ports are now assigned to the dialout group rather than uucp. > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > checked, so: > > SUSE 11.1, var/lock is root:uucp > SUSE 11.2 var/lock is root:root > > A search on Google brought up several comments regarding this, and also > a bugzilla entry. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > However from reading the various posts, some of which are in the bugzilla > entry, it appears that many distros may be, or have changed to this > configuration, and this will undoubtedly break several things, rxtx > included. > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > no lock file option during configure, and that solved his problem. > > As this issue will probably take some time to get resolved across all the > various Linux distros, it might be worth considering changing the default > on the Linux build of rxtx not to use lockfiles, or provide the two > versions of the lib in the binary archive. > > Thanks for your indulgence > > Andy > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Wed Feb 3 12:07:02 2010 From: andy at g0poy.com (Andy Eskelson) Date: Wed, 3 Feb 2010 19:07:02 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> Message-ID: <20100203190702.1b0e7015@workstation.site> Thanks Daniel, I am aware of the permissions problem, I have had a udev rules to solve this for other programs for some time. . I don't think that this is the same problem. as far as I can understand things, the lock files are written in var/lock. Previously var/lock and dev/tty-whatever were the same group. Now with var/lock owned by and with a group of root:root anything other than root cannot create a lock file. Even minicom is broken by this change. This change is going to have quite a few knock-on effects I think. Andy On Wed, 3 Feb 2010 15:33:23 -0300 Daniel Morales Salas wrote: > Hi > > I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > group did not work as it used to be in earlier versions of linux distros, > causing RXTX to not work as non root user. > > The problem appears because the existense of UDEV, now you MUST add a RULE > so the group (uucp or whatever) have access (Read, Write, Execute) to the > Serial Port. > > To solve the problem, without needing to recompile RXTX, you must add a rule > to grant permissions (0666) to the group for the device or port (tty*, > ttyUSB*, etc). I do not remember now what is the line i added but when i > come back home i will give it to you (i am at work now). > > Greetings ! > > 2010/2/3 > > > Hello RXTX group, > > > > I have just joined this group, and this is my first posting. > > I wanted to pass on some information regarding rxtx, so apologies if > > this has been brought up before. I have searched back through the > > archives but nothing specific came up. > > > > I am not a Java programmer, and I only came across rxtx a few days ago. > > > > I use a piece of test equipment called a miniVNA > > http://www.miniradiosolutions.com/ > > > > This is a serial USB controlled instrument, and it has control software > > available for MS windows, and a very old and now non-working Linux > > application. > > > > A few days ago Dietmar, DL2SBA released a Java application to control the > > miniVNA, obviously this application makes use of rxtx. > > > > The program worked fine on Windows, so I set about installing it onto > > Linux. I use SUSE11.1 After a few false starts, I got the system running > > fairly easily, sorting out the file locking by adding the uucp group to > > the users account as suggested (I used the 2.2pre binary files) I then > > passed the install instructions onto another miniVNA user, who also uses > > SUSE, but he ran into problems. To cut a long story short, he was > > also having file lock problems, but the uucp fix did not work. Digging > > into his system I found that there have been some changes in SUSE 11.2. > > > > tty ports are now assigned to the dialout group rather than uucp. > > > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > checked, so: > > > > SUSE 11.1, var/lock is root:uucp > > SUSE 11.2 var/lock is root:root > > > > A search on Google brought up several comments regarding this, and also > > a bugzilla entry. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > However from reading the various posts, some of which are in the bugzilla > > entry, it appears that many distros may be, or have changed to this > > configuration, and this will undoubtedly break several things, rxtx > > included. > > > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > > no lock file option during configure, and that solved his problem. > > > > As this issue will probably take some time to get resolved across all the > > various Linux distros, it might be worth considering changing the default > > on the Linux build of rxtx not to use lockfiles, or provide the two > > versions of the lib in the binary archive. > > > > Thanks for your indulgence > > > > Andy > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From thisdyingdream at gmail.com Wed Feb 3 12:32:35 2010 From: thisdyingdream at gmail.com (Steven Harms) Date: Wed, 3 Feb 2010 14:32:35 -0500 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203190702.1b0e7015@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: This is currently a bug in OpenSUSE that affects more than just rxtx, and is a result of unified udev rules. You can work around this by making udev change the group back to uucp until something more happens. https://bugzilla.novell.com/show_bug.cgi?id=552095 Thanks, Steve On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > Thanks Daniel, > > I am aware of the permissions problem, I have had a udev rules to solve > this for other programs for some time. > . > I don't think that this is the same problem. as far as I can understand > things, the lock files are written in var/lock. Previously var/lock and > dev/tty-whatever were the same group. Now with var/lock owned by and with > a group of root:root anything other than root cannot create a lock > file. Even minicom is broken by this change. > > This change is going to have quite a few knock-on effects I think. > > > Andy > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > Daniel Morales Salas wrote: > >> Hi >> >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp >> group did not work as it used to be in earlier versions of linux distros, >> causing RXTX to not work as non root user. >> >> The problem appears because the existense of UDEV, now you MUST add a RULE >> so the group (uucp or whatever) have access (Read, Write, Execute) to the >> Serial Port. >> >> To solve the problem, without needing to recompile RXTX, you must add a rule >> to grant permissions (0666) to the group for the device or port (tty*, >> ttyUSB*, etc). I do not remember now what is the line i added but when i >> come back home i will give it to you (i am at work now). >> >> Greetings ! >> >> 2010/2/3 >> >> > Hello RXTX group, >> > >> > I have just joined this group, and this is my first posting. >> > I wanted to pass on ?some information regarding rxtx, so apologies if >> > this has been brought up before. I have searched back through the >> > archives but nothing specific came up. >> > >> > I am not a Java programmer, and I only came across rxtx a few days ago. >> > >> > I use a piece of test equipment called a miniVNA >> > http://www.miniradiosolutions.com/ >> > >> > This is a serial USB controlled instrument, and it has control software >> > available for MS windows, and a very old and now non-working Linux >> > application. >> > >> > A few days ago Dietmar, DL2SBA released a Java application to control the >> > miniVNA, obviously this application makes use of rxtx. >> > >> > The program worked fine on Windows, so I set about installing it onto >> > Linux. I use SUSE11.1 After a few false starts, I got the system running >> > fairly easily, sorting out the file locking by adding the uucp group to >> > the users account as suggested (I used the 2.2pre binary files) I then >> > passed the install instructions onto another miniVNA user, who also uses >> > SUSE, but he ran into problems. To cut a long story short, he was >> > also having file lock problems, but the uucp fix did not work. Digging >> > into his system I found that there have been some changes in SUSE 11.2. >> > >> > tty ports are now assigned to the dialout group rather than uucp. >> > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be >> > checked, so: >> > >> > SUSE 11.1, var/lock is root:uucp >> > SUSE 11.2 var/lock is root:root >> > >> > A search on Google brought up several comments regarding this, and also >> > a ?bugzilla entry. >> > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 >> > >> > However from reading the various posts, some of which are in the bugzilla >> > entry, it appears that many distros may be, or have changed to this >> > configuration, and this will undoubtedly break several things, rxtx >> > included. >> > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the >> > no lock file option during configure, and that solved his problem. >> > >> > As this issue will probably take some time to get resolved across all the >> > various Linux distros, it might be worth considering changing the default >> > on the Linux build of rxtx not to use lockfiles, or provide the two >> > versions of the lib in the binary archive. >> > >> > Thanks for your indulgence >> > >> > Andy >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> >> >> >> -- >> Atte: >> Daniel Dario Morales Salas >> Ingeniero Civil en Computaci?n e Inform?tica >> Tel?fono: 02 684 3417 >> Celular: 09 643 1802 >> Santiago, Chile > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 WWW: http://www.sharms.org/blog From andy at g0poy.com Wed Feb 3 17:58:29 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 00:58:29 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: <20100204005829.7dc944e1@workstation.site> Thanks Steve, changing the serial ports back the uucp is not a big problem. I have a udev rule that can be easily modified already. However I cannot see any way of dealing with the var/lock problem apart from making it writable to all. Any thoughts? Andy On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms wrote: > This is currently a bug in OpenSUSE that affects more than just rxtx, > and is a result of unified udev rules. You can work around this by > making udev change the group back to uucp until something more > happens. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > Thanks, > > Steve > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > Thanks Daniel, > > > > I am aware of the permissions problem, I have had a udev rules to solve > > this for other programs for some time. > > . > > I don't think that this is the same problem. as far as I can understand > > things, the lock files are written in var/lock. Previously var/lock and > > dev/tty-whatever were the same group. Now with var/lock owned by and with > > a group of root:root anything other than root cannot create a lock > > file. Even minicom is broken by this change. > > > > This change is going to have quite a few knock-on effects I think. > > > > > > Andy > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > Daniel Morales Salas wrote: > > > >> Hi > >> > >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > >> group did not work as it used to be in earlier versions of linux distros, > >> causing RXTX to not work as non root user. > >> > >> The problem appears because the existense of UDEV, now you MUST add a RULE > >> so the group (uucp or whatever) have access (Read, Write, Execute) to the > >> Serial Port. > >> > >> To solve the problem, without needing to recompile RXTX, you must add a rule > >> to grant permissions (0666) to the group for the device or port (tty*, > >> ttyUSB*, etc). I do not remember now what is the line i added but when i > >> come back home i will give it to you (i am at work now). > >> > >> Greetings ! > >> > >> 2010/2/3 > >> > >> > Hello RXTX group, > >> > > >> > I have just joined this group, and this is my first posting. > >> > I wanted to pass on ?some information regarding rxtx, so apologies if > >> > this has been brought up before. I have searched back through the > >> > archives but nothing specific came up. > >> > > >> > I am not a Java programmer, and I only came across rxtx a few days ago. > >> > > >> > I use a piece of test equipment called a miniVNA > >> > http://www.miniradiosolutions.com/ > >> > > >> > This is a serial USB controlled instrument, and it has control software > >> > available for MS windows, and a very old and now non-working Linux > >> > application. > >> > > >> > A few days ago Dietmar, DL2SBA released a Java application to control the > >> > miniVNA, obviously this application makes use of rxtx. > >> > > >> > The program worked fine on Windows, so I set about installing it onto > >> > Linux. I use SUSE11.1 After a few false starts, I got the system running > >> > fairly easily, sorting out the file locking by adding the uucp group to > >> > the users account as suggested (I used the 2.2pre binary files) I then > >> > passed the install instructions onto another miniVNA user, who also uses > >> > SUSE, but he ran into problems. To cut a long story short, he was > >> > also having file lock problems, but the uucp fix did not work. Digging > >> > into his system I found that there have been some changes in SUSE 11.2. > >> > > >> > tty ports are now assigned to the dialout group rather than uucp. > >> > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > >> > checked, so: > >> > > >> > SUSE 11.1, var/lock is root:uucp > >> > SUSE 11.2 var/lock is root:root > >> > > >> > A search on Google brought up several comments regarding this, and also > >> > a ?bugzilla entry. > >> > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > >> > > >> > However from reading the various posts, some of which are in the bugzilla > >> > entry, it appears that many distros may be, or have changed to this > >> > configuration, and this will undoubtedly break several things, rxtx > >> > included. > >> > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the > >> > no lock file option during configure, and that solved his problem. > >> > > >> > As this issue will probably take some time to get resolved across all the > >> > various Linux distros, it might be worth considering changing the default > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > >> > versions of the lib in the binary archive. > >> > > >> > Thanks for your indulgence > >> > > >> > Andy > >> > > >> > _______________________________________________ > >> > Rxtx mailing list > >> > Rxtx at qbang.org > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > >> > >> > >> > >> -- > >> Atte: > >> Daniel Dario Morales Salas > >> Ingeniero Civil en Computaci?n e Inform?tica > >> Tel?fono: 02 684 3417 > >> Celular: 09 643 1802 > >> Santiago, Chile > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > WWW: http://www.sharms.org/blog From damorales at gmail.com Wed Feb 3 18:26:38 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 22:26:38 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100204005829.7dc944e1@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: Hello I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva 2010 this is what i get: drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ and i don't have ANY problem with lock files and RXTX in my java software. All i had to do was add this rule to udev: # serial KERNEL=="tty*", GROUP="uucp", MODE="0666" and that was all. Of course my user (metalklesk) is part of uucp group. I did not make /var/lock writable to all users. Greetings ! 2010/2/3 Andy Eskelson > Thanks Steve, > > changing the serial ports back the uucp is not a big problem. I have a > udev rule that can be easily modified already. However I cannot see any > way of dealing with the var/lock problem apart from making it writable to > all. Any thoughts? > > Andy > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > wrote: > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > and is a result of unified udev rules. You can work around this by > > making udev change the group back to uucp until something more > > happens. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > Thanks, > > > > Steve > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > Thanks Daniel, > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > this for other programs for some time. > > > . > > > I don't think that this is the same problem. as far as I can understand > > > things, the lock files are written in var/lock. Previously var/lock and > > > dev/tty-whatever were the same group. Now with var/lock owned by and > with > > > a group of root:root anything other than root cannot create a lock > > > file. Even minicom is broken by this change. > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > Daniel Morales Salas wrote: > > > > > >> Hi > > >> > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > the uucp > > >> group did not work as it used to be in earlier versions of linux > distros, > > >> causing RXTX to not work as non root user. > > >> > > >> The problem appears because the existense of UDEV, now you MUST add a > RULE > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > the > > >> Serial Port. > > >> > > >> To solve the problem, without needing to recompile RXTX, you must add > a rule > > >> to grant permissions (0666) to the group for the device or port (tty*, > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > i > > >> come back home i will give it to you (i am at work now). > > >> > > >> Greetings ! > > >> > > >> 2010/2/3 > > >> > > >> > Hello RXTX group, > > >> > > > >> > I have just joined this group, and this is my first posting. > > >> > I wanted to pass on some information regarding rxtx, so apologies > if > > >> > this has been brought up before. I have searched back through the > > >> > archives but nothing specific came up. > > >> > > > >> > I am not a Java programmer, and I only came across rxtx a few days > ago. > > >> > > > >> > I use a piece of test equipment called a miniVNA > > >> > http://www.miniradiosolutions.com/ > > >> > > > >> > This is a serial USB controlled instrument, and it has control > software > > >> > available for MS windows, and a very old and now non-working Linux > > >> > application. > > >> > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > control the > > >> > miniVNA, obviously this application makes use of rxtx. > > >> > > > >> > The program worked fine on Windows, so I set about installing it > onto > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > running > > >> > fairly easily, sorting out the file locking by adding the uucp group > to > > >> > the users account as suggested (I used the 2.2pre binary files) I > then > > >> > passed the install instructions onto another miniVNA user, who also > uses > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > >> > also having file lock problems, but the uucp fix did not work. > Digging > > >> > into his system I found that there have been some changes in SUSE > 11.2. > > >> > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > >> > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > >> > checked, so: > > >> > > > >> > SUSE 11.1, var/lock is root:uucp > > >> > SUSE 11.2 var/lock is root:root > > >> > > > >> > A search on Google brought up several comments regarding this, and > also > > >> > a bugzilla entry. > > >> > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > >> > > > >> > However from reading the various posts, some of which are in the > bugzilla > > >> > entry, it appears that many distros may be, or have changed to this > > >> > configuration, and this will undoubtedly break several things, rxtx > > >> > included. > > >> > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > with the > > >> > no lock file option during configure, and that solved his problem. > > >> > > > >> > As this issue will probably take some time to get resolved across > all the > > >> > various Linux distros, it might be worth considering changing the > default > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > >> > versions of the lib in the binary archive. > > >> > > > >> > Thanks for your indulgence > > >> > > > >> > Andy > > >> > > > >> > _______________________________________________ > > >> > Rxtx mailing list > > >> > Rxtx at qbang.org > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > >> > > > >> > > >> > > >> > > >> -- > > >> Atte: > > >> Daniel Dario Morales Salas > > >> Ingeniero Civil en Computaci?n e Inform?tica > > >> Tel?fono: 02 684 3417 > > >> Celular: 09 643 1802 > > >> Santiago, Chile > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at qbang.org > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > -- > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > WWW: http://www.sharms.org/blog > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Thu Feb 4 05:31:46 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 12:31:46 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: <20100204123146.6cffeb67@workstation.site> Thank's for the confirmation. Something odd is going on somewhere in SUSE 11.2. I'll have to build up a local SUSE11.2 system to see if I can nail down exactly what is going on. Something is blocking the lockfiles in var/lock. The net is nice, but it's a bit difficult trying to work out what is going on what the machine in question is in Germany and I'm in the UK :-) Andy On Wed, 3 Feb 2010 22:26:38 -0300 Daniel Morales Salas wrote: > Hello > > I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva > 2010 this is what i get: > > drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ > > and i don't have ANY problem with lock files and RXTX in my java software. > All i had to do was add this rule to udev: > > # serial > KERNEL=="tty*", GROUP="uucp", MODE="0666" > > and that was all. Of course my user (metalklesk) is part of uucp group. > I did not make /var/lock writable to all users. > > Greetings ! > > 2010/2/3 Andy Eskelson > > > Thanks Steve, > > > > changing the serial ports back the uucp is not a big problem. I have a > > udev rule that can be easily modified already. However I cannot see any > > way of dealing with the var/lock problem apart from making it writable to > > all. Any thoughts? > > > > Andy > > > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > > wrote: > > > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > > and is a result of unified udev rules. You can work around this by > > > making udev change the group back to uucp until something more > > > happens. > > > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > > > Thanks, > > > > > > Steve > > > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > > Thanks Daniel, > > > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > > this for other programs for some time. > > > > . > > > > I don't think that this is the same problem. as far as I can understand > > > > things, the lock files are written in var/lock. Previously var/lock and > > > > dev/tty-whatever were the same group. Now with var/lock owned by and > > with > > > > a group of root:root anything other than root cannot create a lock > > > > file. Even minicom is broken by this change. > > > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > > Daniel Morales Salas wrote: > > > > > > > >> Hi > > > >> > > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > > the uucp > > > >> group did not work as it used to be in earlier versions of linux > > distros, > > > >> causing RXTX to not work as non root user. > > > >> > > > >> The problem appears because the existense of UDEV, now you MUST add a > > RULE > > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > > the > > > >> Serial Port. > > > >> > > > >> To solve the problem, without needing to recompile RXTX, you must add > > a rule > > > >> to grant permissions (0666) to the group for the device or port (tty*, > > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > > i > > > >> come back home i will give it to you (i am at work now). > > > >> > > > >> Greetings ! > > > >> > > > >> 2010/2/3 > > > >> > > > >> > Hello RXTX group, > > > >> > > > > >> > I have just joined this group, and this is my first posting. > > > >> > I wanted to pass on some information regarding rxtx, so apologies > > if > > > >> > this has been brought up before. I have searched back through the > > > >> > archives but nothing specific came up. > > > >> > > > > >> > I am not a Java programmer, and I only came across rxtx a few days > > ago. > > > >> > > > > >> > I use a piece of test equipment called a miniVNA > > > >> > http://www.miniradiosolutions.com/ > > > >> > > > > >> > This is a serial USB controlled instrument, and it has control > > software > > > >> > available for MS windows, and a very old and now non-working Linux > > > >> > application. > > > >> > > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > > control the > > > >> > miniVNA, obviously this application makes use of rxtx. > > > >> > > > > >> > The program worked fine on Windows, so I set about installing it > > onto > > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > > running > > > >> > fairly easily, sorting out the file locking by adding the uucp group > > to > > > >> > the users account as suggested (I used the 2.2pre binary files) I > > then > > > >> > passed the install instructions onto another miniVNA user, who also > > uses > > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > > >> > also having file lock problems, but the uucp fix did not work. > > Digging > > > >> > into his system I found that there have been some changes in SUSE > > 11.2. > > > >> > > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > > >> > > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > > >> > checked, so: > > > >> > > > > >> > SUSE 11.1, var/lock is root:uucp > > > >> > SUSE 11.2 var/lock is root:root > > > >> > > > > >> > A search on Google brought up several comments regarding this, and > > also > > > >> > a bugzilla entry. > > > >> > > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > >> > > > > >> > However from reading the various posts, some of which are in the > > bugzilla > > > >> > entry, it appears that many distros may be, or have changed to this > > > >> > configuration, and this will undoubtedly break several things, rxtx > > > >> > included. > > > >> > > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > > with the > > > >> > no lock file option during configure, and that solved his problem. > > > >> > > > > >> > As this issue will probably take some time to get resolved across > > all the > > > >> > various Linux distros, it might be worth considering changing the > > default > > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > > >> > versions of the lib in the binary archive. > > > >> > > > > >> > Thanks for your indulgence > > > >> > > > > >> > Andy > > > >> > > > > >> > _______________________________________________ > > > >> > Rxtx mailing list > > > >> > Rxtx at qbang.org > > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > > >> > > > > >> > > > >> > > > >> > > > >> -- > > > >> Atte: > > > >> Daniel Dario Morales Salas > > > >> Ingeniero Civil en Computaci?n e Inform?tica > > > >> Tel?fono: 02 684 3417 > > > >> Celular: 09 643 1802 > > > >> Santiago, Chile > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at qbang.org > > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > > > -- > > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > > > WWW: http://www.sharms.org/blog > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From Bob_Jacobsen at lbl.gov Thu Feb 4 09:26:49 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Thu, 4 Feb 2010 08:26:49 -0800 Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 Message-ID: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're using RXTX-2.2pre2, although it emits the known message about "Version mismatch". WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 After the usual messing around, we've got it working on 11 Windows versions, multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ have things working rarely say so, so I don't know whether anybody has gotten it to work on 10.4 or not. The problem encountered is this: dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib dyld: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib followed by the JVM crashing hard. I've got those dump files if that would help. Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If so, is there a patch I can get and build? Thanks Bob -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From tjarvi at qbang.org Thu Feb 4 14:22:21 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 4 Feb 2010 14:22:21 -0700 (MST) Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 In-Reply-To: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> References: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> Message-ID: On Thu, 4 Feb 2010, Bob Jacobsen wrote: > We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're > using RXTX-2.2pre2, although it emits the known message about "Version > mismatch". > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > > After the usual messing around, we've got it working on 11 Windows versions, > multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with > a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ > have things working rarely say so, so I don't know whether anybody has gotten > it to work on 10.4 or not. > > The problem encountered is this: > > dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > dyld: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > followed by the JVM crashing hard. I've got those dump files if that would > help. > > Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If > so, is there a patch I can get and build? > Hi Bob, I talked to a coworker about the problem you ran into. It appears that it is possible to target 'older' Mac systems through makefile configuration changes. "Configuring a Makefile-Based Project If you have a makefile-based project, you can also take advantage of SDK-based development, by adding the appropriate options to your compile and link commands. Using SDKs in makefile-based projects requires GCC 4.0 or later. To choose an SDK, you use the -isysroot option with the compiler and the -syslibroot option with the linker. Both options require that you specify the full path to the desired SDK directory. To set the Deployment OS version in a makefile, use a makefile variable of the form: ENVP= MACOSX_DEPLOYMENT_TARGET=10.4. To use this variable in your makefile, include it in front of your compile and link commands." http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html Or build on the oldest system you want to support. -- Trent Jarvi tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Thu Feb 4 14:56:19 2010 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Thu, 4 Feb 2010 14:56:19 -0700 Subject: [Rxtx] RXTX on 64 Bit Redhat In-Reply-To: References: <4ec9eab61001281448g3dd84910r867619948a4e0d7a@mail.gmail.com> Message-ID: Trent -- Finally fixed all my build related issues. I ran into another issue. On one of my machines my JDK is returning multiple folders for the "java.ext.dirs" (java.ext.dirs -> /opt/jdk1.6.0_17/jre/lib/ext:/usr/java/packages/lib/ext) system property. As a result my JVM wasn't able to detect the gnu.io.rxtx.properties. I am attaching a patch for RXTXCommDriver.java file to check for multiple locations. Also i have to assign permission 660 to all my dev ports to be located by RXTX. Pawan ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 5:12 PM To: Trent Jarvi Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Here is the error i get when i build the src from release-2-1-7 -bash-3.2$ make ( \ \ cd i686-pc-linux-gnu; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/ jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I/opt/jav a1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec - c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialImp.lo;\ if [ "Serial" = "Serial" ]; then \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I /opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_tim espec -c /home/jb_stg/rxtx/rxtx-devel/./src/fuserImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ else \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo; \ fi; \ ) gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/inclu de -I/opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need _timespec -c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -fPIC -DPIC -o /hom e/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/.libs/SerialImp.o /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:25:29: error: gnu_io_RXTXPort.h: No such file or directory In file included from /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:113: /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:91: error: expected specifier-qua lifier-list before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'jobject' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:408: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:409: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:410: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:411: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:415: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:416: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:417: error: expected '=', ',', '; ', 'asm' or '__attribute__' before 'is_interrupted' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:418: error: expected declaration specifiers or '...' before 'jint' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:424: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:441: error: expected ')' before ' *' token ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 4:57 PM To: Santosh Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Santosh -- Thank you. That fixed the issue. All -- What CVS branch or release should i use to get the latest RXTX src code. Pawan ________________________________ From: Santosh [mailto:santosh.ry at gmail.com] Sent: Thursday, January 28, 2010 3:49 PM To: Kharbanda, Pawan Cc: Trent Jarvi; rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat error "./configure: /bin/sh^M: bad interpreter: No such file or directory". I think you need to run dos2unix on script files before compiling. Thanks, Santosh On Thu, Jan 28, 2010 at 5:33 PM, Kharbanda, Pawan > wrote: Trent -- We are upgrading our exisiting OS and JDK on a project that rely heavily on RXTX api's. We are now using JDK1.6 32 bit (build 1.6.0_17-b04) and RedHat 5 on a 64 bit machine. Linux tocrhstg02.dot.state.co.us 2.6.18-164.6.1.el5 #1 SMP Tue Oct 27 11:30:06 EDT 2009 i686 i686 i386 GNU/Linux Red Hat Enterprise Linux Server release 5.4 (Tikanga) I tried to run version 2.1.7 r2 on it but not able to see any of my Digi ports I was able to access only /dev/ttyS0 (physical ports). Not sure if the problem is with the Digi driver or RXTX. I tried to open a Digi port with minicom and it worked fine. I also tried to get latest from CVS (rxtx-devel) and when I do "configure" I see this error "./configure: /bin/sh^M: bad interpreter: No such file or directory". Can someone please help me with this? Thanks for the help. Pawan _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch.txt URL: From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 01:02:21 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 13:32:21 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> My serial port driver(apparently) does not support receive timeout.I registered an event listener for DATA_AVAILABLE. However, the control never seems to come out of the 'while' loop.Shouldn't the InputStream.read return a '-1' immediately if no data is available (this seems to be the default operation)? This was tried on a x86 Linux desktop using rxtx-2.1-7 I've added the snippet for clarity: /******************************************************************************************************************************************************************************/ mySerialPort.enableReceiveThreshold(2000);//Trying to set a time limit for read calls System.out.println(mySerialPort.isReceiveTimeoutEnabled()); // I get FALSE, so its not supported on hardware. mySerialPort.addEventListener(this); mySerialPort.notifyOnDataAvailable(true);//register a event with //my SerialEvent listener implementation: public void serialEvent(SerialPortEvent arg0) { int newData=0; switch(arg0.getEventType()){ case SerialPortEvent.DATA_AVAILABLE: while (newData != -1) { try { newData = is.read();//This should eventually return a -1 if no data is available within a timeout.PROBLEM!! System.out.println("Got a byte from port:"+newData); if (newData == -1) { break; } } catch (IOException ex) { System.err.println(ex); return; } } break; } return; } /******************************************************************************************************************************************************************************/ Thanks and regards, Ravi From michael.erskine at ketech.com Wed Feb 3 02:26:50 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 09:26:50 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From michael.erskine at ketech.com Wed Feb 3 05:03:30 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 12:03:30 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > Michael Erskine > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > > Your event handler should handle the event and return immediately so that its > controlling thread can handle other events. I recommend a single read in the > following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) > reads all available bytes up to the size of the buffer returning the number of > bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } After posting this I considered the glaring possibility of the rawbuf read buffer being too small to receive all the available bytes and perhaps skipping data: after all, I'm guessing that is why we see so many posts asking for help with blocking implementations of read event handlers looping on "while(bytes are available)". I've spent this morning writing an extensive multi-threaded unit test suite that includes tests with a tiny buffer compared to the amount of data available and found that no data was being skipped. I now want to know why! The SerialPortEvent.DATA_AVAILABLE event must be being fired again if there is more data available on the input stream. If that is the case then it should be heavily documented with good examples in the wiki to avoid the types of developer anguish we see so regularly. BTW: I'm not at liberty to post the JUnit tests as they use my company's unit test suite framework. Regards, Michael Erskine. From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 06:18:04 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 18:48:04 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Hello Michael, I tried out your suggestion but the problem is that the read(rawbuf) blocks until the entire length of the rawbuf array has been read (blocking). I cannot decide on a reasonable size of the array because it varies from 2 bytes to as much as 50 byes (i'm communicating with a modem,each response is of a different length), which is why i wanted to use non blocking calls. But on a side note, read(byte[]) in turn calls the read() in a loop.In the native C function, the read is supposed to return a -1 upon timeout.But my driver does not support timeout.The default timeout value is zero and the linux select call upon zero time out causes an infinite wait.What am i missing...... Thanks and regards, Ravi Date: Wed, 3 Feb 2010 09:26:50 +0000 From: Michael Erskine To: "rxtx at qbang.org" Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: Content-Type: text/plain; charset="us-ascii" > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From m.kirkland at comcast.net Wed Feb 3 06:46:03 2010 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 3 Feb 2010 05:46:03 -0800 Subject: [Rxtx] One port blocking another port In-Reply-To: References: Message-ID: <68768633814F4D7D86761D34F0764FE0@bengal.net> It turns out this is caused by having the RTS/CTS flow control turned on and me not providing a true on the RTS pin. Somehow it seems the port timing out on a read allows the write to proceed. This is not an issue for my application but I wonder if the write should not proceed until the RTS pin is true even if a read times out. mk -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Monday, January 25, 2010 7:48 PM To: Mike Kirkland Cc: rxtx at qbang.org Subject: Re: [Rxtx] One port blocking another port On Mon, 25 Jan 2010, Mike Kirkland wrote: > > Hi All, > > ? > > I have a program that reads from one com port and writes to another com > port. It also does the same thing in reverse (reads from the second com port > and writes to the first one. It basically ties two com ports together. > > ? > > One port is very chatty and has a consent stream of data. The other port has > very little data. > > ? > > Both ports use a 5000 ms (5 second) time out. > > ? > > The issue I am having is that is appears that the first port?s write to the > second port is blocked while the second port is waiting for input. The first > port?s write proceeds only after the second port has timed out. > > ? > > I suppose I could have something twisted around in my code but I was > wondering if this is a know issue? > Hi Kirk, I've not seen a report like this. Perhaps some simple reproduction code will reveal a problem on your end or help us identify a problem in rxtx. I think there are several users doing multiport communication. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Wed Feb 3 07:03:58 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:03:58 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Message-ID: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> 2010/2/3 Ravishankar N > Hello Michael, > [..] > But on a side note, read(byte[]) in turn calls the read() in a loop.In the > native C function, the read is supposed to return a -1 upon timeout.But my > driver > does not support timeout.The default timeout value is zero and the linux > select call upon zero time out causes an infinite wait.What am i > missing...... > > When I have tested RXTX between platforms, I have observed "hangup" inside JNI driver when no data in Linux, is normal thing. Solution was setting the timeout for RXTX when no data from JNI driver. Something like that: commPort.enableReceiveTimeout(10); And it works perfect.... The only difference is that I am NOT using events - I am using continous read in separate thread and if data is available, is parsed and transferred to application using exception. Regards Mariusz > Thanks and regards, > Ravi > > Date: Wed, 3 Feb 2010 09:26:50 +0000 > From: Michael Erskine > To: "rxtx at qbang.org" > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > Message-ID: > > > Content-Type: text/plain; charset="us-ascii" > > > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of > > Ravishankar N > > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > > > My serial port driver(apparently) does not support receive timeout.I > > registered an event listener for DATA_AVAILABLE. However, the control > never > > seems to come out of the 'while' loop.Shouldn't the > > InputStream.read return a '-1' immediately if no data is available (this > seems > > to be the default operation)? > > Your event handler should handle the event and return immediately so that > its controlling thread can handle other events. I recommend a single read in > the following manner: rawbuf is a byte[] of "reasonable" size and the > read(byte[]) reads all available bytes up to the size of the buffer > returning the number of bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } > > This style of reading has worked for me with RXTX on Linux and Windows XP > for a good few years now in railway industry communications systems. Any > timeouts (largely unnecessary in my applications) can be handled elsewhere, > usually at a higher layer. > > Regards, > Michael Erskine. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Feb 3 07:22:55 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 3 Feb 2010 09:22:55 -0500 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: I'm guessing that this is driver specific. I recently had to support a select()/poll() infrastructure for a linux serial DD, its certainly non trivial to support async IO, so I suspect the problem in this case has to do with missing poll infrastructure in the device driver. This also has to coupled with special open flags for the device (which is within the rxtx code) The key routines within a 2.6 kernel linux device driver are shown below (if you have access to it for your particular device) are indicated below (here is a snippet from my device driver c code that supports polling/select). User space code to test this shown below also, note that the device needs to be opened with the O_NONBLOCK option to support the select/poll api // device driver code ..... /* * File operations supported by this driver. */ static struct file_operations iop_fops = { .owner = THIS_MODULE, .check_flags= iop_check_flags, .ioctl = iop_ioctl, .open = iop_open, .poll = iop_poll, // SUPPORT FOR SELECT/POLL infrastructure .read = iop_read, .release = iop_release, .write = iop_write, }; /** * Select/poll/epoll infrastructure. * * @param file * @param wait * * @return */ static unsigned int iop_poll(struct file *filp, poll_table *wait) { struct iop_device *devp = (struct iop_device *)filp->private_data; // the poll_table wait arg is an opaque pointer poll_wait(filp, &devp->readq, wait); // return from poll indicating whether we have read/write data unsigned int mask = 0; if (kfifo_len(devp->rx_fifo)) { mask |= (POLLIN | POLLRDNORM); } // @JC We don't do select on write yet // if (kfifo_len(devp->tx_fifo)) { // mask |= (POLLOUT | POLLWRNORM); // } // Only print out while debugging // if (mask != 0) { // printk (KERN_INFO "%s: [%04x]\n", __FUNCTION__, mask); // } return mask; } /** * device driver blocking and non blocking read function. This * function reads the requested number of bytes from the read * kfifo blocking as required. * * @param filp * @param buf * @param count * @param f_pos * * @return */ static ssize_t iop_read(struct file *filp, char __user *buf, size_t count, loff_t * ppos) { // access appropriate device struct struct iop_device *devp = (struct iop_device *) filp->private_data; ssize_t retval; // support non blocking mode (default) by checking if the kfifo is empty first if ((kfifo_len(devp->rx_fifo)==0) && (filp->f_flags & O_NONBLOCK)) { return -EAGAIN; } // wait for rx_fifo to receive data via receive interrupts retval = wait_event_interruptible(devp->readq, kfifo_len(devp->rx_fifo) != 0); // check for some error condition if (retval) { printk (KERN_ERR "%s: wait_event_interruptible returned[%d]\n", __FUNCTION__, retval); return retval; } // copy max requested bytes from rx_fifo to device buffer // this may still leave bytes in the kfifo for a subsequent read // if we are reading in a loop retval = kfifo_get(devp->rx_fifo, devp->rxbuf, count); // printk (KERN_INFO "%s: [%d] byte(s)\n", __FUNCTION__, retval); if (copy_to_user(buf, devp->rxbuf, retval)) { printk (KERN_ERR "%s: problem copying rx_fifo data to user buffer\n", __FUNCTION__); return -EFAULT; } return retval; } // a selection of my user space code reading via select()/poll()..... // user space open code iop_fd = ::open( deviceName.data(), O_RDWR | O_NONBLOCK); while ((bytes_to_expect - bytes_read) > 0) { // must reinitialize these between select calls fd_set readfds; FD_ZERO( &readfds ); FD_SET( iop_fd, &readfds ); // 1s sec read polling timeout struct timeval timeout; timeout.tv_sec = 1; timeout.tv_usec = 0; int rc = select( FD_SETSIZE, &readfds, NULL, NULL, &timeout ); // read from file when descriptor // indicates data available without blocking if ((rc > 0) && FD_ISSET(iop_fd, &readfds)) { // read into the appropriate offset within the rx_buf int temp = read(iop_fd, rx_buf + bytes_read, bytes_to_expect - bytes_read); if (!temp) { printf("EOF detected with %d bytes expected\n", bytes_to_expect - bytes_read); } else { bytes_read += temp; } } else if (rc < 0){ printf("%s: select on [%s], bytes_read[%d], errno=%d\n", __FUNCTION__, thread_args->device, bytes_read, errno); } else { printf("%s: select on [%s], bytes_read[%d], timeout\n", __FUNCTION__, thread_args->device, bytes_read); } } On Wed, Feb 3, 2010 at 9:03 AM, Mariusz Dec wrote: > > > 2010/2/3 Ravishankar N > >> Hello Michael, >> [..] >> >> But on a side note, read(byte[]) in turn calls the read() in a loop.In the >> native C function, the read is supposed to return a -1 upon timeout.But my >> driver >> does not support timeout.The default timeout value is zero and the linux >> select call upon zero time out causes an infinite wait.What am i >> missing...... >> >> > When I have tested RXTX between platforms, I have observed "hangup" inside > JNI driver when no data in Linux, is normal thing. > > Solution was setting the timeout for RXTX when no data from JNI driver. > > Something like that: > > commPort.enableReceiveTimeout(10); > > And it works perfect.... > > The only difference is that I am NOT using events - I am using continous > read in separate thread and if data is available, is parsed and transferred > to application using exception. > > Regards > Mariusz > > > >> Thanks and regards, >> Ravi >> >> Date: Wed, 3 Feb 2010 09:26:50 +0000 >> From: Michael Erskine >> To: "rxtx at qbang.org" >> Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? >> Message-ID: >> >> >> Content-Type: text/plain; charset="us-ascii" >> >> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >> Of >> > Ravishankar N >> > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? >> > >> > My serial port driver(apparently) does not support receive timeout.I >> > registered an event listener for DATA_AVAILABLE. However, the control >> never >> > seems to come out of the 'while' loop.Shouldn't the >> > InputStream.read return a '-1' immediately if no data is available (this >> seems >> > to be the default operation)? >> >> Your event handler should handle the event and return immediately so that >> its controlling thread can handle other events. I recommend a single read in >> the following manner: rawbuf is a byte[] of "reasonable" size and the >> read(byte[]) reads all available bytes up to the size of the buffer >> returning the number of bytes actually read... >> >> case SerialPortEvent.DATA_AVAILABLE: >> try { >> int i = is.read(rawbuf); >> if (i == -1) { >> << process EOF condition - should never happen >> >> return; >> } >> << process bytes (rawbuf, i); >> >> return; >> } catch (IOException e) { >> << promptly deal with exception >> >> return; >> } >> >> This style of reading has worked for me with RXTX on Linux and Windows XP >> for a good few years now in railway industry communications systems. Any >> timeouts (largely unnecessary in my applications) can be handled elsewhere, >> usually at a higher layer. >> >> Regards, >> Michael Erskine. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Feb 3 07:33:27 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:33:27 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: <73a89f361002030633j682610afia48dc7accd8e049b@mail.gmail.com> 2010/2/3 John Coffey > I'm guessing that this is driver specific. I recently had to support a > select()/poll() infrastructure for a linux serial DD, its certainly non > trivial to support async IO, so I suspect the problem in this case has to do > with missing poll infrastructure in the device driver. This also has to > coupled with special open flags for the device (which is within the rxtx > code) > > Yes, you are right, it may be driver specific, but in my case I haven't changed blocking JNI driver. I have added ONLY one call to RXTX method mentioned in my previous post and blocking (as seen as from Java app) gone out... Maybe this is not elegant, but works without problem in my app. I am using only FTDI chips and their drivers from couple of years and maybe this is the kind of the way to have no many problems with serial as well? Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From andyrxtx at g0poy.co.uk Wed Feb 3 11:09:04 2010 From: andyrxtx at g0poy.co.uk (andyrxtx at g0poy.co.uk) Date: Wed, 3 Feb 2010 18:09:04 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes Message-ID: <20100203180904.164f24dd@workstation.site> ?Hello RXTX group, I have just joined this group, and this is my first posting. I wanted to pass on some information regarding rxtx, so apologies if this has been brought up before. I have searched back through the archives but nothing specific came up. I am not a Java programmer, and I only came across rxtx a few days ago. I use a piece of test equipment called a miniVNA http://www.miniradiosolutions.com/ This is a serial USB controlled instrument, and it has control software available for MS windows, and a very old and now non-working Linux application. A few days ago Dietmar, DL2SBA released a Java application to control the miniVNA, obviously this application makes use of rxtx. The program worked fine on Windows, so I set about installing it onto Linux. I use SUSE11.1 After a few false starts, I got the system running fairly easily, sorting out the file locking by adding the uucp group to the users account as suggested (I used the 2.2pre binary files) I then passed the install instructions onto another miniVNA user, who also uses SUSE, but he ran into problems. To cut a long story short, he was also having file lock problems, but the uucp fix did not work. Digging into his system I found that there have been some changes in SUSE 11.2. tty ports are now assigned to the dialout group rather than uucp. A hint in the rxtx INSTALL file, suggested that var/lock needs to be checked, so: SUSE 11.1, var/lock is root:uucp SUSE 11.2 var/lock is root:root A search on Google brought up several comments regarding this, and also a bugzilla entry. https://bugzilla.novell.com/show_bug.cgi?id=552095 However from reading the various posts, some of which are in the bugzilla entry, it appears that many distros may be, or have changed to this configuration, and this will undoubtedly break several things, rxtx included. I solved my fellow SUSE users problem by compiling the rxtx libs with the no lock file option during configure, and that solved his problem. As this issue will probably take some time to get resolved across all the various Linux distros, it might be worth considering changing the default on the Linux build of rxtx not to use lockfiles, or provide the two versions of the lib in the binary archive. Thanks for your indulgence Andy From damorales at gmail.com Wed Feb 3 11:33:23 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 15:33:23 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203180904.164f24dd@workstation.site> References: <20100203180904.164f24dd@workstation.site> Message-ID: Hi I had the same problem in Mandriva 2010 and yes, adding the user to the uucp group did not work as it used to be in earlier versions of linux distros, causing RXTX to not work as non root user. The problem appears because the existense of UDEV, now you MUST add a RULE so the group (uucp or whatever) have access (Read, Write, Execute) to the Serial Port. To solve the problem, without needing to recompile RXTX, you must add a rule to grant permissions (0666) to the group for the device or port (tty*, ttyUSB*, etc). I do not remember now what is the line i added but when i come back home i will give it to you (i am at work now). Greetings ! 2010/2/3 > Hello RXTX group, > > I have just joined this group, and this is my first posting. > I wanted to pass on some information regarding rxtx, so apologies if > this has been brought up before. I have searched back through the > archives but nothing specific came up. > > I am not a Java programmer, and I only came across rxtx a few days ago. > > I use a piece of test equipment called a miniVNA > http://www.miniradiosolutions.com/ > > This is a serial USB controlled instrument, and it has control software > available for MS windows, and a very old and now non-working Linux > application. > > A few days ago Dietmar, DL2SBA released a Java application to control the > miniVNA, obviously this application makes use of rxtx. > > The program worked fine on Windows, so I set about installing it onto > Linux. I use SUSE11.1 After a few false starts, I got the system running > fairly easily, sorting out the file locking by adding the uucp group to > the users account as suggested (I used the 2.2pre binary files) I then > passed the install instructions onto another miniVNA user, who also uses > SUSE, but he ran into problems. To cut a long story short, he was > also having file lock problems, but the uucp fix did not work. Digging > into his system I found that there have been some changes in SUSE 11.2. > > tty ports are now assigned to the dialout group rather than uucp. > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > checked, so: > > SUSE 11.1, var/lock is root:uucp > SUSE 11.2 var/lock is root:root > > A search on Google brought up several comments regarding this, and also > a bugzilla entry. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > However from reading the various posts, some of which are in the bugzilla > entry, it appears that many distros may be, or have changed to this > configuration, and this will undoubtedly break several things, rxtx > included. > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > no lock file option during configure, and that solved his problem. > > As this issue will probably take some time to get resolved across all the > various Linux distros, it might be worth considering changing the default > on the Linux build of rxtx not to use lockfiles, or provide the two > versions of the lib in the binary archive. > > Thanks for your indulgence > > Andy > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Wed Feb 3 12:07:02 2010 From: andy at g0poy.com (Andy Eskelson) Date: Wed, 3 Feb 2010 19:07:02 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> Message-ID: <20100203190702.1b0e7015@workstation.site> Thanks Daniel, I am aware of the permissions problem, I have had a udev rules to solve this for other programs for some time. . I don't think that this is the same problem. as far as I can understand things, the lock files are written in var/lock. Previously var/lock and dev/tty-whatever were the same group. Now with var/lock owned by and with a group of root:root anything other than root cannot create a lock file. Even minicom is broken by this change. This change is going to have quite a few knock-on effects I think. Andy On Wed, 3 Feb 2010 15:33:23 -0300 Daniel Morales Salas wrote: > Hi > > I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > group did not work as it used to be in earlier versions of linux distros, > causing RXTX to not work as non root user. > > The problem appears because the existense of UDEV, now you MUST add a RULE > so the group (uucp or whatever) have access (Read, Write, Execute) to the > Serial Port. > > To solve the problem, without needing to recompile RXTX, you must add a rule > to grant permissions (0666) to the group for the device or port (tty*, > ttyUSB*, etc). I do not remember now what is the line i added but when i > come back home i will give it to you (i am at work now). > > Greetings ! > > 2010/2/3 > > > Hello RXTX group, > > > > I have just joined this group, and this is my first posting. > > I wanted to pass on some information regarding rxtx, so apologies if > > this has been brought up before. I have searched back through the > > archives but nothing specific came up. > > > > I am not a Java programmer, and I only came across rxtx a few days ago. > > > > I use a piece of test equipment called a miniVNA > > http://www.miniradiosolutions.com/ > > > > This is a serial USB controlled instrument, and it has control software > > available for MS windows, and a very old and now non-working Linux > > application. > > > > A few days ago Dietmar, DL2SBA released a Java application to control the > > miniVNA, obviously this application makes use of rxtx. > > > > The program worked fine on Windows, so I set about installing it onto > > Linux. I use SUSE11.1 After a few false starts, I got the system running > > fairly easily, sorting out the file locking by adding the uucp group to > > the users account as suggested (I used the 2.2pre binary files) I then > > passed the install instructions onto another miniVNA user, who also uses > > SUSE, but he ran into problems. To cut a long story short, he was > > also having file lock problems, but the uucp fix did not work. Digging > > into his system I found that there have been some changes in SUSE 11.2. > > > > tty ports are now assigned to the dialout group rather than uucp. > > > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > checked, so: > > > > SUSE 11.1, var/lock is root:uucp > > SUSE 11.2 var/lock is root:root > > > > A search on Google brought up several comments regarding this, and also > > a bugzilla entry. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > However from reading the various posts, some of which are in the bugzilla > > entry, it appears that many distros may be, or have changed to this > > configuration, and this will undoubtedly break several things, rxtx > > included. > > > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > > no lock file option during configure, and that solved his problem. > > > > As this issue will probably take some time to get resolved across all the > > various Linux distros, it might be worth considering changing the default > > on the Linux build of rxtx not to use lockfiles, or provide the two > > versions of the lib in the binary archive. > > > > Thanks for your indulgence > > > > Andy > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From thisdyingdream at gmail.com Wed Feb 3 12:32:35 2010 From: thisdyingdream at gmail.com (Steven Harms) Date: Wed, 3 Feb 2010 14:32:35 -0500 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203190702.1b0e7015@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: This is currently a bug in OpenSUSE that affects more than just rxtx, and is a result of unified udev rules. You can work around this by making udev change the group back to uucp until something more happens. https://bugzilla.novell.com/show_bug.cgi?id=552095 Thanks, Steve On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > Thanks Daniel, > > I am aware of the permissions problem, I have had a udev rules to solve > this for other programs for some time. > . > I don't think that this is the same problem. as far as I can understand > things, the lock files are written in var/lock. Previously var/lock and > dev/tty-whatever were the same group. Now with var/lock owned by and with > a group of root:root anything other than root cannot create a lock > file. Even minicom is broken by this change. > > This change is going to have quite a few knock-on effects I think. > > > Andy > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > Daniel Morales Salas wrote: > >> Hi >> >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp >> group did not work as it used to be in earlier versions of linux distros, >> causing RXTX to not work as non root user. >> >> The problem appears because the existense of UDEV, now you MUST add a RULE >> so the group (uucp or whatever) have access (Read, Write, Execute) to the >> Serial Port. >> >> To solve the problem, without needing to recompile RXTX, you must add a rule >> to grant permissions (0666) to the group for the device or port (tty*, >> ttyUSB*, etc). I do not remember now what is the line i added but when i >> come back home i will give it to you (i am at work now). >> >> Greetings ! >> >> 2010/2/3 >> >> > Hello RXTX group, >> > >> > I have just joined this group, and this is my first posting. >> > I wanted to pass on ?some information regarding rxtx, so apologies if >> > this has been brought up before. I have searched back through the >> > archives but nothing specific came up. >> > >> > I am not a Java programmer, and I only came across rxtx a few days ago. >> > >> > I use a piece of test equipment called a miniVNA >> > http://www.miniradiosolutions.com/ >> > >> > This is a serial USB controlled instrument, and it has control software >> > available for MS windows, and a very old and now non-working Linux >> > application. >> > >> > A few days ago Dietmar, DL2SBA released a Java application to control the >> > miniVNA, obviously this application makes use of rxtx. >> > >> > The program worked fine on Windows, so I set about installing it onto >> > Linux. I use SUSE11.1 After a few false starts, I got the system running >> > fairly easily, sorting out the file locking by adding the uucp group to >> > the users account as suggested (I used the 2.2pre binary files) I then >> > passed the install instructions onto another miniVNA user, who also uses >> > SUSE, but he ran into problems. To cut a long story short, he was >> > also having file lock problems, but the uucp fix did not work. Digging >> > into his system I found that there have been some changes in SUSE 11.2. >> > >> > tty ports are now assigned to the dialout group rather than uucp. >> > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be >> > checked, so: >> > >> > SUSE 11.1, var/lock is root:uucp >> > SUSE 11.2 var/lock is root:root >> > >> > A search on Google brought up several comments regarding this, and also >> > a ?bugzilla entry. >> > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 >> > >> > However from reading the various posts, some of which are in the bugzilla >> > entry, it appears that many distros may be, or have changed to this >> > configuration, and this will undoubtedly break several things, rxtx >> > included. >> > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the >> > no lock file option during configure, and that solved his problem. >> > >> > As this issue will probably take some time to get resolved across all the >> > various Linux distros, it might be worth considering changing the default >> > on the Linux build of rxtx not to use lockfiles, or provide the two >> > versions of the lib in the binary archive. >> > >> > Thanks for your indulgence >> > >> > Andy >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> >> >> >> -- >> Atte: >> Daniel Dario Morales Salas >> Ingeniero Civil en Computaci?n e Inform?tica >> Tel?fono: 02 684 3417 >> Celular: 09 643 1802 >> Santiago, Chile > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 WWW: http://www.sharms.org/blog From andy at g0poy.com Wed Feb 3 17:58:29 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 00:58:29 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: <20100204005829.7dc944e1@workstation.site> Thanks Steve, changing the serial ports back the uucp is not a big problem. I have a udev rule that can be easily modified already. However I cannot see any way of dealing with the var/lock problem apart from making it writable to all. Any thoughts? Andy On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms wrote: > This is currently a bug in OpenSUSE that affects more than just rxtx, > and is a result of unified udev rules. You can work around this by > making udev change the group back to uucp until something more > happens. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > Thanks, > > Steve > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > Thanks Daniel, > > > > I am aware of the permissions problem, I have had a udev rules to solve > > this for other programs for some time. > > . > > I don't think that this is the same problem. as far as I can understand > > things, the lock files are written in var/lock. Previously var/lock and > > dev/tty-whatever were the same group. Now with var/lock owned by and with > > a group of root:root anything other than root cannot create a lock > > file. Even minicom is broken by this change. > > > > This change is going to have quite a few knock-on effects I think. > > > > > > Andy > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > Daniel Morales Salas wrote: > > > >> Hi > >> > >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > >> group did not work as it used to be in earlier versions of linux distros, > >> causing RXTX to not work as non root user. > >> > >> The problem appears because the existense of UDEV, now you MUST add a RULE > >> so the group (uucp or whatever) have access (Read, Write, Execute) to the > >> Serial Port. > >> > >> To solve the problem, without needing to recompile RXTX, you must add a rule > >> to grant permissions (0666) to the group for the device or port (tty*, > >> ttyUSB*, etc). I do not remember now what is the line i added but when i > >> come back home i will give it to you (i am at work now). > >> > >> Greetings ! > >> > >> 2010/2/3 > >> > >> > Hello RXTX group, > >> > > >> > I have just joined this group, and this is my first posting. > >> > I wanted to pass on ?some information regarding rxtx, so apologies if > >> > this has been brought up before. I have searched back through the > >> > archives but nothing specific came up. > >> > > >> > I am not a Java programmer, and I only came across rxtx a few days ago. > >> > > >> > I use a piece of test equipment called a miniVNA > >> > http://www.miniradiosolutions.com/ > >> > > >> > This is a serial USB controlled instrument, and it has control software > >> > available for MS windows, and a very old and now non-working Linux > >> > application. > >> > > >> > A few days ago Dietmar, DL2SBA released a Java application to control the > >> > miniVNA, obviously this application makes use of rxtx. > >> > > >> > The program worked fine on Windows, so I set about installing it onto > >> > Linux. I use SUSE11.1 After a few false starts, I got the system running > >> > fairly easily, sorting out the file locking by adding the uucp group to > >> > the users account as suggested (I used the 2.2pre binary files) I then > >> > passed the install instructions onto another miniVNA user, who also uses > >> > SUSE, but he ran into problems. To cut a long story short, he was > >> > also having file lock problems, but the uucp fix did not work. Digging > >> > into his system I found that there have been some changes in SUSE 11.2. > >> > > >> > tty ports are now assigned to the dialout group rather than uucp. > >> > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > >> > checked, so: > >> > > >> > SUSE 11.1, var/lock is root:uucp > >> > SUSE 11.2 var/lock is root:root > >> > > >> > A search on Google brought up several comments regarding this, and also > >> > a ?bugzilla entry. > >> > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > >> > > >> > However from reading the various posts, some of which are in the bugzilla > >> > entry, it appears that many distros may be, or have changed to this > >> > configuration, and this will undoubtedly break several things, rxtx > >> > included. > >> > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the > >> > no lock file option during configure, and that solved his problem. > >> > > >> > As this issue will probably take some time to get resolved across all the > >> > various Linux distros, it might be worth considering changing the default > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > >> > versions of the lib in the binary archive. > >> > > >> > Thanks for your indulgence > >> > > >> > Andy > >> > > >> > _______________________________________________ > >> > Rxtx mailing list > >> > Rxtx at qbang.org > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > >> > >> > >> > >> -- > >> Atte: > >> Daniel Dario Morales Salas > >> Ingeniero Civil en Computaci?n e Inform?tica > >> Tel?fono: 02 684 3417 > >> Celular: 09 643 1802 > >> Santiago, Chile > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > WWW: http://www.sharms.org/blog From damorales at gmail.com Wed Feb 3 18:26:38 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 22:26:38 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100204005829.7dc944e1@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: Hello I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva 2010 this is what i get: drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ and i don't have ANY problem with lock files and RXTX in my java software. All i had to do was add this rule to udev: # serial KERNEL=="tty*", GROUP="uucp", MODE="0666" and that was all. Of course my user (metalklesk) is part of uucp group. I did not make /var/lock writable to all users. Greetings ! 2010/2/3 Andy Eskelson > Thanks Steve, > > changing the serial ports back the uucp is not a big problem. I have a > udev rule that can be easily modified already. However I cannot see any > way of dealing with the var/lock problem apart from making it writable to > all. Any thoughts? > > Andy > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > wrote: > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > and is a result of unified udev rules. You can work around this by > > making udev change the group back to uucp until something more > > happens. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > Thanks, > > > > Steve > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > Thanks Daniel, > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > this for other programs for some time. > > > . > > > I don't think that this is the same problem. as far as I can understand > > > things, the lock files are written in var/lock. Previously var/lock and > > > dev/tty-whatever were the same group. Now with var/lock owned by and > with > > > a group of root:root anything other than root cannot create a lock > > > file. Even minicom is broken by this change. > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > Daniel Morales Salas wrote: > > > > > >> Hi > > >> > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > the uucp > > >> group did not work as it used to be in earlier versions of linux > distros, > > >> causing RXTX to not work as non root user. > > >> > > >> The problem appears because the existense of UDEV, now you MUST add a > RULE > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > the > > >> Serial Port. > > >> > > >> To solve the problem, without needing to recompile RXTX, you must add > a rule > > >> to grant permissions (0666) to the group for the device or port (tty*, > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > i > > >> come back home i will give it to you (i am at work now). > > >> > > >> Greetings ! > > >> > > >> 2010/2/3 > > >> > > >> > Hello RXTX group, > > >> > > > >> > I have just joined this group, and this is my first posting. > > >> > I wanted to pass on some information regarding rxtx, so apologies > if > > >> > this has been brought up before. I have searched back through the > > >> > archives but nothing specific came up. > > >> > > > >> > I am not a Java programmer, and I only came across rxtx a few days > ago. > > >> > > > >> > I use a piece of test equipment called a miniVNA > > >> > http://www.miniradiosolutions.com/ > > >> > > > >> > This is a serial USB controlled instrument, and it has control > software > > >> > available for MS windows, and a very old and now non-working Linux > > >> > application. > > >> > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > control the > > >> > miniVNA, obviously this application makes use of rxtx. > > >> > > > >> > The program worked fine on Windows, so I set about installing it > onto > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > running > > >> > fairly easily, sorting out the file locking by adding the uucp group > to > > >> > the users account as suggested (I used the 2.2pre binary files) I > then > > >> > passed the install instructions onto another miniVNA user, who also > uses > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > >> > also having file lock problems, but the uucp fix did not work. > Digging > > >> > into his system I found that there have been some changes in SUSE > 11.2. > > >> > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > >> > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > >> > checked, so: > > >> > > > >> > SUSE 11.1, var/lock is root:uucp > > >> > SUSE 11.2 var/lock is root:root > > >> > > > >> > A search on Google brought up several comments regarding this, and > also > > >> > a bugzilla entry. > > >> > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > >> > > > >> > However from reading the various posts, some of which are in the > bugzilla > > >> > entry, it appears that many distros may be, or have changed to this > > >> > configuration, and this will undoubtedly break several things, rxtx > > >> > included. > > >> > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > with the > > >> > no lock file option during configure, and that solved his problem. > > >> > > > >> > As this issue will probably take some time to get resolved across > all the > > >> > various Linux distros, it might be worth considering changing the > default > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > >> > versions of the lib in the binary archive. > > >> > > > >> > Thanks for your indulgence > > >> > > > >> > Andy > > >> > > > >> > _______________________________________________ > > >> > Rxtx mailing list > > >> > Rxtx at qbang.org > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > >> > > > >> > > >> > > >> > > >> -- > > >> Atte: > > >> Daniel Dario Morales Salas > > >> Ingeniero Civil en Computaci?n e Inform?tica > > >> Tel?fono: 02 684 3417 > > >> Celular: 09 643 1802 > > >> Santiago, Chile > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at qbang.org > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > -- > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > WWW: http://www.sharms.org/blog > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Thu Feb 4 05:31:46 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 12:31:46 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: <20100204123146.6cffeb67@workstation.site> Thank's for the confirmation. Something odd is going on somewhere in SUSE 11.2. I'll have to build up a local SUSE11.2 system to see if I can nail down exactly what is going on. Something is blocking the lockfiles in var/lock. The net is nice, but it's a bit difficult trying to work out what is going on what the machine in question is in Germany and I'm in the UK :-) Andy On Wed, 3 Feb 2010 22:26:38 -0300 Daniel Morales Salas wrote: > Hello > > I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva > 2010 this is what i get: > > drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ > > and i don't have ANY problem with lock files and RXTX in my java software. > All i had to do was add this rule to udev: > > # serial > KERNEL=="tty*", GROUP="uucp", MODE="0666" > > and that was all. Of course my user (metalklesk) is part of uucp group. > I did not make /var/lock writable to all users. > > Greetings ! > > 2010/2/3 Andy Eskelson > > > Thanks Steve, > > > > changing the serial ports back the uucp is not a big problem. I have a > > udev rule that can be easily modified already. However I cannot see any > > way of dealing with the var/lock problem apart from making it writable to > > all. Any thoughts? > > > > Andy > > > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > > wrote: > > > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > > and is a result of unified udev rules. You can work around this by > > > making udev change the group back to uucp until something more > > > happens. > > > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > > > Thanks, > > > > > > Steve > > > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > > Thanks Daniel, > > > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > > this for other programs for some time. > > > > . > > > > I don't think that this is the same problem. as far as I can understand > > > > things, the lock files are written in var/lock. Previously var/lock and > > > > dev/tty-whatever were the same group. Now with var/lock owned by and > > with > > > > a group of root:root anything other than root cannot create a lock > > > > file. Even minicom is broken by this change. > > > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > > Daniel Morales Salas wrote: > > > > > > > >> Hi > > > >> > > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > > the uucp > > > >> group did not work as it used to be in earlier versions of linux > > distros, > > > >> causing RXTX to not work as non root user. > > > >> > > > >> The problem appears because the existense of UDEV, now you MUST add a > > RULE > > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > > the > > > >> Serial Port. > > > >> > > > >> To solve the problem, without needing to recompile RXTX, you must add > > a rule > > > >> to grant permissions (0666) to the group for the device or port (tty*, > > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > > i > > > >> come back home i will give it to you (i am at work now). > > > >> > > > >> Greetings ! > > > >> > > > >> 2010/2/3 > > > >> > > > >> > Hello RXTX group, > > > >> > > > > >> > I have just joined this group, and this is my first posting. > > > >> > I wanted to pass on some information regarding rxtx, so apologies > > if > > > >> > this has been brought up before. I have searched back through the > > > >> > archives but nothing specific came up. > > > >> > > > > >> > I am not a Java programmer, and I only came across rxtx a few days > > ago. > > > >> > > > > >> > I use a piece of test equipment called a miniVNA > > > >> > http://www.miniradiosolutions.com/ > > > >> > > > > >> > This is a serial USB controlled instrument, and it has control > > software > > > >> > available for MS windows, and a very old and now non-working Linux > > > >> > application. > > > >> > > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > > control the > > > >> > miniVNA, obviously this application makes use of rxtx. > > > >> > > > > >> > The program worked fine on Windows, so I set about installing it > > onto > > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > > running > > > >> > fairly easily, sorting out the file locking by adding the uucp group > > to > > > >> > the users account as suggested (I used the 2.2pre binary files) I > > then > > > >> > passed the install instructions onto another miniVNA user, who also > > uses > > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > > >> > also having file lock problems, but the uucp fix did not work. > > Digging > > > >> > into his system I found that there have been some changes in SUSE > > 11.2. > > > >> > > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > > >> > > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > > >> > checked, so: > > > >> > > > > >> > SUSE 11.1, var/lock is root:uucp > > > >> > SUSE 11.2 var/lock is root:root > > > >> > > > > >> > A search on Google brought up several comments regarding this, and > > also > > > >> > a bugzilla entry. > > > >> > > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > >> > > > > >> > However from reading the various posts, some of which are in the > > bugzilla > > > >> > entry, it appears that many distros may be, or have changed to this > > > >> > configuration, and this will undoubtedly break several things, rxtx > > > >> > included. > > > >> > > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > > with the > > > >> > no lock file option during configure, and that solved his problem. > > > >> > > > > >> > As this issue will probably take some time to get resolved across > > all the > > > >> > various Linux distros, it might be worth considering changing the > > default > > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > > >> > versions of the lib in the binary archive. > > > >> > > > > >> > Thanks for your indulgence > > > >> > > > > >> > Andy > > > >> > > > > >> > _______________________________________________ > > > >> > Rxtx mailing list > > > >> > Rxtx at qbang.org > > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > > >> > > > > >> > > > >> > > > >> > > > >> -- > > > >> Atte: > > > >> Daniel Dario Morales Salas > > > >> Ingeniero Civil en Computaci?n e Inform?tica > > > >> Tel?fono: 02 684 3417 > > > >> Celular: 09 643 1802 > > > >> Santiago, Chile > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at qbang.org > > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > > > -- > > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > > > WWW: http://www.sharms.org/blog > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From Bob_Jacobsen at lbl.gov Thu Feb 4 09:26:49 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Thu, 4 Feb 2010 08:26:49 -0800 Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 Message-ID: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're using RXTX-2.2pre2, although it emits the known message about "Version mismatch". WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 After the usual messing around, we've got it working on 11 Windows versions, multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ have things working rarely say so, so I don't know whether anybody has gotten it to work on 10.4 or not. The problem encountered is this: dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib dyld: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib followed by the JVM crashing hard. I've got those dump files if that would help. Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If so, is there a patch I can get and build? Thanks Bob -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From tjarvi at qbang.org Thu Feb 4 14:22:21 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 4 Feb 2010 14:22:21 -0700 (MST) Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 In-Reply-To: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> References: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> Message-ID: On Thu, 4 Feb 2010, Bob Jacobsen wrote: > We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're > using RXTX-2.2pre2, although it emits the known message about "Version > mismatch". > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > > After the usual messing around, we've got it working on 11 Windows versions, > multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with > a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ > have things working rarely say so, so I don't know whether anybody has gotten > it to work on 10.4 or not. > > The problem encountered is this: > > dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > dyld: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > followed by the JVM crashing hard. I've got those dump files if that would > help. > > Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If > so, is there a patch I can get and build? > Hi Bob, I talked to a coworker about the problem you ran into. It appears that it is possible to target 'older' Mac systems through makefile configuration changes. "Configuring a Makefile-Based Project If you have a makefile-based project, you can also take advantage of SDK-based development, by adding the appropriate options to your compile and link commands. Using SDKs in makefile-based projects requires GCC 4.0 or later. To choose an SDK, you use the -isysroot option with the compiler and the -syslibroot option with the linker. Both options require that you specify the full path to the desired SDK directory. To set the Deployment OS version in a makefile, use a makefile variable of the form: ENVP= MACOSX_DEPLOYMENT_TARGET=10.4. To use this variable in your makefile, include it in front of your compile and link commands." http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html Or build on the oldest system you want to support. -- Trent Jarvi tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Thu Feb 4 14:56:19 2010 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Thu, 4 Feb 2010 14:56:19 -0700 Subject: [Rxtx] RXTX on 64 Bit Redhat In-Reply-To: References: <4ec9eab61001281448g3dd84910r867619948a4e0d7a@mail.gmail.com> Message-ID: Trent -- Finally fixed all my build related issues. I ran into another issue. On one of my machines my JDK is returning multiple folders for the "java.ext.dirs" (java.ext.dirs -> /opt/jdk1.6.0_17/jre/lib/ext:/usr/java/packages/lib/ext) system property. As a result my JVM wasn't able to detect the gnu.io.rxtx.properties. I am attaching a patch for RXTXCommDriver.java file to check for multiple locations. Also i have to assign permission 660 to all my dev ports to be located by RXTX. Pawan ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 5:12 PM To: Trent Jarvi Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Here is the error i get when i build the src from release-2-1-7 -bash-3.2$ make ( \ \ cd i686-pc-linux-gnu; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/ jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I/opt/jav a1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec - c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialImp.lo;\ if [ "Serial" = "Serial" ]; then \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I /opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_tim espec -c /home/jb_stg/rxtx/rxtx-devel/./src/fuserImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ else \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo; \ fi; \ ) gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/inclu de -I/opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need _timespec -c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -fPIC -DPIC -o /hom e/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/.libs/SerialImp.o /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:25:29: error: gnu_io_RXTXPort.h: No such file or directory In file included from /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:113: /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:91: error: expected specifier-qua lifier-list before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'jobject' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:408: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:409: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:410: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:411: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:415: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:416: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:417: error: expected '=', ',', '; ', 'asm' or '__attribute__' before 'is_interrupted' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:418: error: expected declaration specifiers or '...' before 'jint' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:424: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:441: error: expected ')' before ' *' token ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 4:57 PM To: Santosh Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Santosh -- Thank you. That fixed the issue. All -- What CVS branch or release should i use to get the latest RXTX src code. Pawan ________________________________ From: Santosh [mailto:santosh.ry at gmail.com] Sent: Thursday, January 28, 2010 3:49 PM To: Kharbanda, Pawan Cc: Trent Jarvi; rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat error "./configure: /bin/sh^M: bad interpreter: No such file or directory". I think you need to run dos2unix on script files before compiling. Thanks, Santosh On Thu, Jan 28, 2010 at 5:33 PM, Kharbanda, Pawan > wrote: Trent -- We are upgrading our exisiting OS and JDK on a project that rely heavily on RXTX api's. We are now using JDK1.6 32 bit (build 1.6.0_17-b04) and RedHat 5 on a 64 bit machine. Linux tocrhstg02.dot.state.co.us 2.6.18-164.6.1.el5 #1 SMP Tue Oct 27 11:30:06 EDT 2009 i686 i686 i386 GNU/Linux Red Hat Enterprise Linux Server release 5.4 (Tikanga) I tried to run version 2.1.7 r2 on it but not able to see any of my Digi ports I was able to access only /dev/ttyS0 (physical ports). Not sure if the problem is with the Digi driver or RXTX. I tried to open a Digi port with minicom and it worked fine. I also tried to get latest from CVS (rxtx-devel) and when I do "configure" I see this error "./configure: /bin/sh^M: bad interpreter: No such file or directory". Can someone please help me with this? Thanks for the help. Pawan _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch.txt URL: From juan.vicente.l.g at gmail.com Sat Feb 13 04:44:17 2010 From: juan.vicente.l.g at gmail.com (Juan Vicente Lopez Gutierrez) Date: Sat, 13 Feb 2010 12:44:17 +0100 Subject: [Rxtx] RXTX in macmini OSX 10.5 Message-ID: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> Hello. My name is Juanvi and I'm from Spain. I tried to launch a software created by me in the library CXR java to send information through the serial port and I can not make it work. In windows if I've done but not mac. I have a mac mini with OSX 10.5 and have read in the list of web mail that you CXR if you have managed to make it work on that operating system. I need you help me please. Do I make the mistake that shows me java: run: Stable Library =============================== Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 gnu.io.PortInUseException: Unknow Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:26) at TwoWatSerialComm.main(TwoWaySerialComm.java:106) Experimental: JNI_OnLoad called. GENERACION CORRECTA (total time: 0 seconds) I do not have permission to access the serial port, do not know. Os agradeceria much to sit down. A greeting and thanks. Pardon my English. Juanvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 01:02:21 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 13:32:21 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> My serial port driver(apparently) does not support receive timeout.I registered an event listener for DATA_AVAILABLE. However, the control never seems to come out of the 'while' loop.Shouldn't the InputStream.read return a '-1' immediately if no data is available (this seems to be the default operation)? This was tried on a x86 Linux desktop using rxtx-2.1-7 I've added the snippet for clarity: /******************************************************************************************************************************************************************************/ mySerialPort.enableReceiveThreshold(2000);//Trying to set a time limit for read calls System.out.println(mySerialPort.isReceiveTimeoutEnabled()); // I get FALSE, so its not supported on hardware. mySerialPort.addEventListener(this); mySerialPort.notifyOnDataAvailable(true);//register a event with //my SerialEvent listener implementation: public void serialEvent(SerialPortEvent arg0) { int newData=0; switch(arg0.getEventType()){ case SerialPortEvent.DATA_AVAILABLE: while (newData != -1) { try { newData = is.read();//This should eventually return a -1 if no data is available within a timeout.PROBLEM!! System.out.println("Got a byte from port:"+newData); if (newData == -1) { break; } } catch (IOException ex) { System.err.println(ex); return; } } break; } return; } /******************************************************************************************************************************************************************************/ Thanks and regards, Ravi From michael.erskine at ketech.com Wed Feb 3 02:26:50 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 09:26:50 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From michael.erskine at ketech.com Wed Feb 3 05:03:30 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 12:03:30 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > Michael Erskine > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > > Your event handler should handle the event and return immediately so that its > controlling thread can handle other events. I recommend a single read in the > following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) > reads all available bytes up to the size of the buffer returning the number of > bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } After posting this I considered the glaring possibility of the rawbuf read buffer being too small to receive all the available bytes and perhaps skipping data: after all, I'm guessing that is why we see so many posts asking for help with blocking implementations of read event handlers looping on "while(bytes are available)". I've spent this morning writing an extensive multi-threaded unit test suite that includes tests with a tiny buffer compared to the amount of data available and found that no data was being skipped. I now want to know why! The SerialPortEvent.DATA_AVAILABLE event must be being fired again if there is more data available on the input stream. If that is the case then it should be heavily documented with good examples in the wiki to avoid the types of developer anguish we see so regularly. BTW: I'm not at liberty to post the JUnit tests as they use my company's unit test suite framework. Regards, Michael Erskine. From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 06:18:04 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 18:48:04 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Hello Michael, I tried out your suggestion but the problem is that the read(rawbuf) blocks until the entire length of the rawbuf array has been read (blocking). I cannot decide on a reasonable size of the array because it varies from 2 bytes to as much as 50 byes (i'm communicating with a modem,each response is of a different length), which is why i wanted to use non blocking calls. But on a side note, read(byte[]) in turn calls the read() in a loop.In the native C function, the read is supposed to return a -1 upon timeout.But my driver does not support timeout.The default timeout value is zero and the linux select call upon zero time out causes an infinite wait.What am i missing...... Thanks and regards, Ravi Date: Wed, 3 Feb 2010 09:26:50 +0000 From: Michael Erskine To: "rxtx at qbang.org" Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: Content-Type: text/plain; charset="us-ascii" > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From m.kirkland at comcast.net Wed Feb 3 06:46:03 2010 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 3 Feb 2010 05:46:03 -0800 Subject: [Rxtx] One port blocking another port In-Reply-To: References: Message-ID: <68768633814F4D7D86761D34F0764FE0@bengal.net> It turns out this is caused by having the RTS/CTS flow control turned on and me not providing a true on the RTS pin. Somehow it seems the port timing out on a read allows the write to proceed. This is not an issue for my application but I wonder if the write should not proceed until the RTS pin is true even if a read times out. mk -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Monday, January 25, 2010 7:48 PM To: Mike Kirkland Cc: rxtx at qbang.org Subject: Re: [Rxtx] One port blocking another port On Mon, 25 Jan 2010, Mike Kirkland wrote: > > Hi All, > > ? > > I have a program that reads from one com port and writes to another com > port. It also does the same thing in reverse (reads from the second com port > and writes to the first one. It basically ties two com ports together. > > ? > > One port is very chatty and has a consent stream of data. The other port has > very little data. > > ? > > Both ports use a 5000 ms (5 second) time out. > > ? > > The issue I am having is that is appears that the first port?s write to the > second port is blocked while the second port is waiting for input. The first > port?s write proceeds only after the second port has timed out. > > ? > > I suppose I could have something twisted around in my code but I was > wondering if this is a know issue? > Hi Kirk, I've not seen a report like this. Perhaps some simple reproduction code will reveal a problem on your end or help us identify a problem in rxtx. I think there are several users doing multiport communication. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Wed Feb 3 07:03:58 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:03:58 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Message-ID: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> 2010/2/3 Ravishankar N > Hello Michael, > [..] > But on a side note, read(byte[]) in turn calls the read() in a loop.In the > native C function, the read is supposed to return a -1 upon timeout.But my > driver > does not support timeout.The default timeout value is zero and the linux > select call upon zero time out causes an infinite wait.What am i > missing...... > > When I have tested RXTX between platforms, I have observed "hangup" inside JNI driver when no data in Linux, is normal thing. Solution was setting the timeout for RXTX when no data from JNI driver. Something like that: commPort.enableReceiveTimeout(10); And it works perfect.... The only difference is that I am NOT using events - I am using continous read in separate thread and if data is available, is parsed and transferred to application using exception. Regards Mariusz > Thanks and regards, > Ravi > > Date: Wed, 3 Feb 2010 09:26:50 +0000 > From: Michael Erskine > To: "rxtx at qbang.org" > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > Message-ID: > > > Content-Type: text/plain; charset="us-ascii" > > > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of > > Ravishankar N > > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > > > My serial port driver(apparently) does not support receive timeout.I > > registered an event listener for DATA_AVAILABLE. However, the control > never > > seems to come out of the 'while' loop.Shouldn't the > > InputStream.read return a '-1' immediately if no data is available (this > seems > > to be the default operation)? > > Your event handler should handle the event and return immediately so that > its controlling thread can handle other events. I recommend a single read in > the following manner: rawbuf is a byte[] of "reasonable" size and the > read(byte[]) reads all available bytes up to the size of the buffer > returning the number of bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } > > This style of reading has worked for me with RXTX on Linux and Windows XP > for a good few years now in railway industry communications systems. Any > timeouts (largely unnecessary in my applications) can be handled elsewhere, > usually at a higher layer. > > Regards, > Michael Erskine. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Feb 3 07:22:55 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 3 Feb 2010 09:22:55 -0500 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: I'm guessing that this is driver specific. I recently had to support a select()/poll() infrastructure for a linux serial DD, its certainly non trivial to support async IO, so I suspect the problem in this case has to do with missing poll infrastructure in the device driver. This also has to coupled with special open flags for the device (which is within the rxtx code) The key routines within a 2.6 kernel linux device driver are shown below (if you have access to it for your particular device) are indicated below (here is a snippet from my device driver c code that supports polling/select). User space code to test this shown below also, note that the device needs to be opened with the O_NONBLOCK option to support the select/poll api // device driver code ..... /* * File operations supported by this driver. */ static struct file_operations iop_fops = { .owner = THIS_MODULE, .check_flags= iop_check_flags, .ioctl = iop_ioctl, .open = iop_open, .poll = iop_poll, // SUPPORT FOR SELECT/POLL infrastructure .read = iop_read, .release = iop_release, .write = iop_write, }; /** * Select/poll/epoll infrastructure. * * @param file * @param wait * * @return */ static unsigned int iop_poll(struct file *filp, poll_table *wait) { struct iop_device *devp = (struct iop_device *)filp->private_data; // the poll_table wait arg is an opaque pointer poll_wait(filp, &devp->readq, wait); // return from poll indicating whether we have read/write data unsigned int mask = 0; if (kfifo_len(devp->rx_fifo)) { mask |= (POLLIN | POLLRDNORM); } // @JC We don't do select on write yet // if (kfifo_len(devp->tx_fifo)) { // mask |= (POLLOUT | POLLWRNORM); // } // Only print out while debugging // if (mask != 0) { // printk (KERN_INFO "%s: [%04x]\n", __FUNCTION__, mask); // } return mask; } /** * device driver blocking and non blocking read function. This * function reads the requested number of bytes from the read * kfifo blocking as required. * * @param filp * @param buf * @param count * @param f_pos * * @return */ static ssize_t iop_read(struct file *filp, char __user *buf, size_t count, loff_t * ppos) { // access appropriate device struct struct iop_device *devp = (struct iop_device *) filp->private_data; ssize_t retval; // support non blocking mode (default) by checking if the kfifo is empty first if ((kfifo_len(devp->rx_fifo)==0) && (filp->f_flags & O_NONBLOCK)) { return -EAGAIN; } // wait for rx_fifo to receive data via receive interrupts retval = wait_event_interruptible(devp->readq, kfifo_len(devp->rx_fifo) != 0); // check for some error condition if (retval) { printk (KERN_ERR "%s: wait_event_interruptible returned[%d]\n", __FUNCTION__, retval); return retval; } // copy max requested bytes from rx_fifo to device buffer // this may still leave bytes in the kfifo for a subsequent read // if we are reading in a loop retval = kfifo_get(devp->rx_fifo, devp->rxbuf, count); // printk (KERN_INFO "%s: [%d] byte(s)\n", __FUNCTION__, retval); if (copy_to_user(buf, devp->rxbuf, retval)) { printk (KERN_ERR "%s: problem copying rx_fifo data to user buffer\n", __FUNCTION__); return -EFAULT; } return retval; } // a selection of my user space code reading via select()/poll()..... // user space open code iop_fd = ::open( deviceName.data(), O_RDWR | O_NONBLOCK); while ((bytes_to_expect - bytes_read) > 0) { // must reinitialize these between select calls fd_set readfds; FD_ZERO( &readfds ); FD_SET( iop_fd, &readfds ); // 1s sec read polling timeout struct timeval timeout; timeout.tv_sec = 1; timeout.tv_usec = 0; int rc = select( FD_SETSIZE, &readfds, NULL, NULL, &timeout ); // read from file when descriptor // indicates data available without blocking if ((rc > 0) && FD_ISSET(iop_fd, &readfds)) { // read into the appropriate offset within the rx_buf int temp = read(iop_fd, rx_buf + bytes_read, bytes_to_expect - bytes_read); if (!temp) { printf("EOF detected with %d bytes expected\n", bytes_to_expect - bytes_read); } else { bytes_read += temp; } } else if (rc < 0){ printf("%s: select on [%s], bytes_read[%d], errno=%d\n", __FUNCTION__, thread_args->device, bytes_read, errno); } else { printf("%s: select on [%s], bytes_read[%d], timeout\n", __FUNCTION__, thread_args->device, bytes_read); } } On Wed, Feb 3, 2010 at 9:03 AM, Mariusz Dec wrote: > > > 2010/2/3 Ravishankar N > >> Hello Michael, >> [..] >> >> But on a side note, read(byte[]) in turn calls the read() in a loop.In the >> native C function, the read is supposed to return a -1 upon timeout.But my >> driver >> does not support timeout.The default timeout value is zero and the linux >> select call upon zero time out causes an infinite wait.What am i >> missing...... >> >> > When I have tested RXTX between platforms, I have observed "hangup" inside > JNI driver when no data in Linux, is normal thing. > > Solution was setting the timeout for RXTX when no data from JNI driver. > > Something like that: > > commPort.enableReceiveTimeout(10); > > And it works perfect.... > > The only difference is that I am NOT using events - I am using continous > read in separate thread and if data is available, is parsed and transferred > to application using exception. > > Regards > Mariusz > > > >> Thanks and regards, >> Ravi >> >> Date: Wed, 3 Feb 2010 09:26:50 +0000 >> From: Michael Erskine >> To: "rxtx at qbang.org" >> Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? >> Message-ID: >> >> >> Content-Type: text/plain; charset="us-ascii" >> >> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >> Of >> > Ravishankar N >> > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? >> > >> > My serial port driver(apparently) does not support receive timeout.I >> > registered an event listener for DATA_AVAILABLE. However, the control >> never >> > seems to come out of the 'while' loop.Shouldn't the >> > InputStream.read return a '-1' immediately if no data is available (this >> seems >> > to be the default operation)? >> >> Your event handler should handle the event and return immediately so that >> its controlling thread can handle other events. I recommend a single read in >> the following manner: rawbuf is a byte[] of "reasonable" size and the >> read(byte[]) reads all available bytes up to the size of the buffer >> returning the number of bytes actually read... >> >> case SerialPortEvent.DATA_AVAILABLE: >> try { >> int i = is.read(rawbuf); >> if (i == -1) { >> << process EOF condition - should never happen >> >> return; >> } >> << process bytes (rawbuf, i); >> >> return; >> } catch (IOException e) { >> << promptly deal with exception >> >> return; >> } >> >> This style of reading has worked for me with RXTX on Linux and Windows XP >> for a good few years now in railway industry communications systems. Any >> timeouts (largely unnecessary in my applications) can be handled elsewhere, >> usually at a higher layer. >> >> Regards, >> Michael Erskine. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Feb 3 07:33:27 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:33:27 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: <73a89f361002030633j682610afia48dc7accd8e049b@mail.gmail.com> 2010/2/3 John Coffey > I'm guessing that this is driver specific. I recently had to support a > select()/poll() infrastructure for a linux serial DD, its certainly non > trivial to support async IO, so I suspect the problem in this case has to do > with missing poll infrastructure in the device driver. This also has to > coupled with special open flags for the device (which is within the rxtx > code) > > Yes, you are right, it may be driver specific, but in my case I haven't changed blocking JNI driver. I have added ONLY one call to RXTX method mentioned in my previous post and blocking (as seen as from Java app) gone out... Maybe this is not elegant, but works without problem in my app. I am using only FTDI chips and their drivers from couple of years and maybe this is the kind of the way to have no many problems with serial as well? Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From andyrxtx at g0poy.co.uk Wed Feb 3 11:09:04 2010 From: andyrxtx at g0poy.co.uk (andyrxtx at g0poy.co.uk) Date: Wed, 3 Feb 2010 18:09:04 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes Message-ID: <20100203180904.164f24dd@workstation.site> ?Hello RXTX group, I have just joined this group, and this is my first posting. I wanted to pass on some information regarding rxtx, so apologies if this has been brought up before. I have searched back through the archives but nothing specific came up. I am not a Java programmer, and I only came across rxtx a few days ago. I use a piece of test equipment called a miniVNA http://www.miniradiosolutions.com/ This is a serial USB controlled instrument, and it has control software available for MS windows, and a very old and now non-working Linux application. A few days ago Dietmar, DL2SBA released a Java application to control the miniVNA, obviously this application makes use of rxtx. The program worked fine on Windows, so I set about installing it onto Linux. I use SUSE11.1 After a few false starts, I got the system running fairly easily, sorting out the file locking by adding the uucp group to the users account as suggested (I used the 2.2pre binary files) I then passed the install instructions onto another miniVNA user, who also uses SUSE, but he ran into problems. To cut a long story short, he was also having file lock problems, but the uucp fix did not work. Digging into his system I found that there have been some changes in SUSE 11.2. tty ports are now assigned to the dialout group rather than uucp. A hint in the rxtx INSTALL file, suggested that var/lock needs to be checked, so: SUSE 11.1, var/lock is root:uucp SUSE 11.2 var/lock is root:root A search on Google brought up several comments regarding this, and also a bugzilla entry. https://bugzilla.novell.com/show_bug.cgi?id=552095 However from reading the various posts, some of which are in the bugzilla entry, it appears that many distros may be, or have changed to this configuration, and this will undoubtedly break several things, rxtx included. I solved my fellow SUSE users problem by compiling the rxtx libs with the no lock file option during configure, and that solved his problem. As this issue will probably take some time to get resolved across all the various Linux distros, it might be worth considering changing the default on the Linux build of rxtx not to use lockfiles, or provide the two versions of the lib in the binary archive. Thanks for your indulgence Andy From damorales at gmail.com Wed Feb 3 11:33:23 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 15:33:23 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203180904.164f24dd@workstation.site> References: <20100203180904.164f24dd@workstation.site> Message-ID: Hi I had the same problem in Mandriva 2010 and yes, adding the user to the uucp group did not work as it used to be in earlier versions of linux distros, causing RXTX to not work as non root user. The problem appears because the existense of UDEV, now you MUST add a RULE so the group (uucp or whatever) have access (Read, Write, Execute) to the Serial Port. To solve the problem, without needing to recompile RXTX, you must add a rule to grant permissions (0666) to the group for the device or port (tty*, ttyUSB*, etc). I do not remember now what is the line i added but when i come back home i will give it to you (i am at work now). Greetings ! 2010/2/3 > Hello RXTX group, > > I have just joined this group, and this is my first posting. > I wanted to pass on some information regarding rxtx, so apologies if > this has been brought up before. I have searched back through the > archives but nothing specific came up. > > I am not a Java programmer, and I only came across rxtx a few days ago. > > I use a piece of test equipment called a miniVNA > http://www.miniradiosolutions.com/ > > This is a serial USB controlled instrument, and it has control software > available for MS windows, and a very old and now non-working Linux > application. > > A few days ago Dietmar, DL2SBA released a Java application to control the > miniVNA, obviously this application makes use of rxtx. > > The program worked fine on Windows, so I set about installing it onto > Linux. I use SUSE11.1 After a few false starts, I got the system running > fairly easily, sorting out the file locking by adding the uucp group to > the users account as suggested (I used the 2.2pre binary files) I then > passed the install instructions onto another miniVNA user, who also uses > SUSE, but he ran into problems. To cut a long story short, he was > also having file lock problems, but the uucp fix did not work. Digging > into his system I found that there have been some changes in SUSE 11.2. > > tty ports are now assigned to the dialout group rather than uucp. > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > checked, so: > > SUSE 11.1, var/lock is root:uucp > SUSE 11.2 var/lock is root:root > > A search on Google brought up several comments regarding this, and also > a bugzilla entry. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > However from reading the various posts, some of which are in the bugzilla > entry, it appears that many distros may be, or have changed to this > configuration, and this will undoubtedly break several things, rxtx > included. > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > no lock file option during configure, and that solved his problem. > > As this issue will probably take some time to get resolved across all the > various Linux distros, it might be worth considering changing the default > on the Linux build of rxtx not to use lockfiles, or provide the two > versions of the lib in the binary archive. > > Thanks for your indulgence > > Andy > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Wed Feb 3 12:07:02 2010 From: andy at g0poy.com (Andy Eskelson) Date: Wed, 3 Feb 2010 19:07:02 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> Message-ID: <20100203190702.1b0e7015@workstation.site> Thanks Daniel, I am aware of the permissions problem, I have had a udev rules to solve this for other programs for some time. . I don't think that this is the same problem. as far as I can understand things, the lock files are written in var/lock. Previously var/lock and dev/tty-whatever were the same group. Now with var/lock owned by and with a group of root:root anything other than root cannot create a lock file. Even minicom is broken by this change. This change is going to have quite a few knock-on effects I think. Andy On Wed, 3 Feb 2010 15:33:23 -0300 Daniel Morales Salas wrote: > Hi > > I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > group did not work as it used to be in earlier versions of linux distros, > causing RXTX to not work as non root user. > > The problem appears because the existense of UDEV, now you MUST add a RULE > so the group (uucp or whatever) have access (Read, Write, Execute) to the > Serial Port. > > To solve the problem, without needing to recompile RXTX, you must add a rule > to grant permissions (0666) to the group for the device or port (tty*, > ttyUSB*, etc). I do not remember now what is the line i added but when i > come back home i will give it to you (i am at work now). > > Greetings ! > > 2010/2/3 > > > Hello RXTX group, > > > > I have just joined this group, and this is my first posting. > > I wanted to pass on some information regarding rxtx, so apologies if > > this has been brought up before. I have searched back through the > > archives but nothing specific came up. > > > > I am not a Java programmer, and I only came across rxtx a few days ago. > > > > I use a piece of test equipment called a miniVNA > > http://www.miniradiosolutions.com/ > > > > This is a serial USB controlled instrument, and it has control software > > available for MS windows, and a very old and now non-working Linux > > application. > > > > A few days ago Dietmar, DL2SBA released a Java application to control the > > miniVNA, obviously this application makes use of rxtx. > > > > The program worked fine on Windows, so I set about installing it onto > > Linux. I use SUSE11.1 After a few false starts, I got the system running > > fairly easily, sorting out the file locking by adding the uucp group to > > the users account as suggested (I used the 2.2pre binary files) I then > > passed the install instructions onto another miniVNA user, who also uses > > SUSE, but he ran into problems. To cut a long story short, he was > > also having file lock problems, but the uucp fix did not work. Digging > > into his system I found that there have been some changes in SUSE 11.2. > > > > tty ports are now assigned to the dialout group rather than uucp. > > > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > checked, so: > > > > SUSE 11.1, var/lock is root:uucp > > SUSE 11.2 var/lock is root:root > > > > A search on Google brought up several comments regarding this, and also > > a bugzilla entry. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > However from reading the various posts, some of which are in the bugzilla > > entry, it appears that many distros may be, or have changed to this > > configuration, and this will undoubtedly break several things, rxtx > > included. > > > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > > no lock file option during configure, and that solved his problem. > > > > As this issue will probably take some time to get resolved across all the > > various Linux distros, it might be worth considering changing the default > > on the Linux build of rxtx not to use lockfiles, or provide the two > > versions of the lib in the binary archive. > > > > Thanks for your indulgence > > > > Andy > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From thisdyingdream at gmail.com Wed Feb 3 12:32:35 2010 From: thisdyingdream at gmail.com (Steven Harms) Date: Wed, 3 Feb 2010 14:32:35 -0500 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203190702.1b0e7015@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: This is currently a bug in OpenSUSE that affects more than just rxtx, and is a result of unified udev rules. You can work around this by making udev change the group back to uucp until something more happens. https://bugzilla.novell.com/show_bug.cgi?id=552095 Thanks, Steve On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > Thanks Daniel, > > I am aware of the permissions problem, I have had a udev rules to solve > this for other programs for some time. > . > I don't think that this is the same problem. as far as I can understand > things, the lock files are written in var/lock. Previously var/lock and > dev/tty-whatever were the same group. Now with var/lock owned by and with > a group of root:root anything other than root cannot create a lock > file. Even minicom is broken by this change. > > This change is going to have quite a few knock-on effects I think. > > > Andy > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > Daniel Morales Salas wrote: > >> Hi >> >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp >> group did not work as it used to be in earlier versions of linux distros, >> causing RXTX to not work as non root user. >> >> The problem appears because the existense of UDEV, now you MUST add a RULE >> so the group (uucp or whatever) have access (Read, Write, Execute) to the >> Serial Port. >> >> To solve the problem, without needing to recompile RXTX, you must add a rule >> to grant permissions (0666) to the group for the device or port (tty*, >> ttyUSB*, etc). I do not remember now what is the line i added but when i >> come back home i will give it to you (i am at work now). >> >> Greetings ! >> >> 2010/2/3 >> >> > Hello RXTX group, >> > >> > I have just joined this group, and this is my first posting. >> > I wanted to pass on ?some information regarding rxtx, so apologies if >> > this has been brought up before. I have searched back through the >> > archives but nothing specific came up. >> > >> > I am not a Java programmer, and I only came across rxtx a few days ago. >> > >> > I use a piece of test equipment called a miniVNA >> > http://www.miniradiosolutions.com/ >> > >> > This is a serial USB controlled instrument, and it has control software >> > available for MS windows, and a very old and now non-working Linux >> > application. >> > >> > A few days ago Dietmar, DL2SBA released a Java application to control the >> > miniVNA, obviously this application makes use of rxtx. >> > >> > The program worked fine on Windows, so I set about installing it onto >> > Linux. I use SUSE11.1 After a few false starts, I got the system running >> > fairly easily, sorting out the file locking by adding the uucp group to >> > the users account as suggested (I used the 2.2pre binary files) I then >> > passed the install instructions onto another miniVNA user, who also uses >> > SUSE, but he ran into problems. To cut a long story short, he was >> > also having file lock problems, but the uucp fix did not work. Digging >> > into his system I found that there have been some changes in SUSE 11.2. >> > >> > tty ports are now assigned to the dialout group rather than uucp. >> > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be >> > checked, so: >> > >> > SUSE 11.1, var/lock is root:uucp >> > SUSE 11.2 var/lock is root:root >> > >> > A search on Google brought up several comments regarding this, and also >> > a ?bugzilla entry. >> > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 >> > >> > However from reading the various posts, some of which are in the bugzilla >> > entry, it appears that many distros may be, or have changed to this >> > configuration, and this will undoubtedly break several things, rxtx >> > included. >> > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the >> > no lock file option during configure, and that solved his problem. >> > >> > As this issue will probably take some time to get resolved across all the >> > various Linux distros, it might be worth considering changing the default >> > on the Linux build of rxtx not to use lockfiles, or provide the two >> > versions of the lib in the binary archive. >> > >> > Thanks for your indulgence >> > >> > Andy >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> >> >> >> -- >> Atte: >> Daniel Dario Morales Salas >> Ingeniero Civil en Computaci?n e Inform?tica >> Tel?fono: 02 684 3417 >> Celular: 09 643 1802 >> Santiago, Chile > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 WWW: http://www.sharms.org/blog From andy at g0poy.com Wed Feb 3 17:58:29 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 00:58:29 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: <20100204005829.7dc944e1@workstation.site> Thanks Steve, changing the serial ports back the uucp is not a big problem. I have a udev rule that can be easily modified already. However I cannot see any way of dealing with the var/lock problem apart from making it writable to all. Any thoughts? Andy On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms wrote: > This is currently a bug in OpenSUSE that affects more than just rxtx, > and is a result of unified udev rules. You can work around this by > making udev change the group back to uucp until something more > happens. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > Thanks, > > Steve > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > Thanks Daniel, > > > > I am aware of the permissions problem, I have had a udev rules to solve > > this for other programs for some time. > > . > > I don't think that this is the same problem. as far as I can understand > > things, the lock files are written in var/lock. Previously var/lock and > > dev/tty-whatever were the same group. Now with var/lock owned by and with > > a group of root:root anything other than root cannot create a lock > > file. Even minicom is broken by this change. > > > > This change is going to have quite a few knock-on effects I think. > > > > > > Andy > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > Daniel Morales Salas wrote: > > > >> Hi > >> > >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > >> group did not work as it used to be in earlier versions of linux distros, > >> causing RXTX to not work as non root user. > >> > >> The problem appears because the existense of UDEV, now you MUST add a RULE > >> so the group (uucp or whatever) have access (Read, Write, Execute) to the > >> Serial Port. > >> > >> To solve the problem, without needing to recompile RXTX, you must add a rule > >> to grant permissions (0666) to the group for the device or port (tty*, > >> ttyUSB*, etc). I do not remember now what is the line i added but when i > >> come back home i will give it to you (i am at work now). > >> > >> Greetings ! > >> > >> 2010/2/3 > >> > >> > Hello RXTX group, > >> > > >> > I have just joined this group, and this is my first posting. > >> > I wanted to pass on ?some information regarding rxtx, so apologies if > >> > this has been brought up before. I have searched back through the > >> > archives but nothing specific came up. > >> > > >> > I am not a Java programmer, and I only came across rxtx a few days ago. > >> > > >> > I use a piece of test equipment called a miniVNA > >> > http://www.miniradiosolutions.com/ > >> > > >> > This is a serial USB controlled instrument, and it has control software > >> > available for MS windows, and a very old and now non-working Linux > >> > application. > >> > > >> > A few days ago Dietmar, DL2SBA released a Java application to control the > >> > miniVNA, obviously this application makes use of rxtx. > >> > > >> > The program worked fine on Windows, so I set about installing it onto > >> > Linux. I use SUSE11.1 After a few false starts, I got the system running > >> > fairly easily, sorting out the file locking by adding the uucp group to > >> > the users account as suggested (I used the 2.2pre binary files) I then > >> > passed the install instructions onto another miniVNA user, who also uses > >> > SUSE, but he ran into problems. To cut a long story short, he was > >> > also having file lock problems, but the uucp fix did not work. Digging > >> > into his system I found that there have been some changes in SUSE 11.2. > >> > > >> > tty ports are now assigned to the dialout group rather than uucp. > >> > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > >> > checked, so: > >> > > >> > SUSE 11.1, var/lock is root:uucp > >> > SUSE 11.2 var/lock is root:root > >> > > >> > A search on Google brought up several comments regarding this, and also > >> > a ?bugzilla entry. > >> > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > >> > > >> > However from reading the various posts, some of which are in the bugzilla > >> > entry, it appears that many distros may be, or have changed to this > >> > configuration, and this will undoubtedly break several things, rxtx > >> > included. > >> > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the > >> > no lock file option during configure, and that solved his problem. > >> > > >> > As this issue will probably take some time to get resolved across all the > >> > various Linux distros, it might be worth considering changing the default > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > >> > versions of the lib in the binary archive. > >> > > >> > Thanks for your indulgence > >> > > >> > Andy > >> > > >> > _______________________________________________ > >> > Rxtx mailing list > >> > Rxtx at qbang.org > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > >> > >> > >> > >> -- > >> Atte: > >> Daniel Dario Morales Salas > >> Ingeniero Civil en Computaci?n e Inform?tica > >> Tel?fono: 02 684 3417 > >> Celular: 09 643 1802 > >> Santiago, Chile > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > WWW: http://www.sharms.org/blog From damorales at gmail.com Wed Feb 3 18:26:38 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 22:26:38 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100204005829.7dc944e1@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: Hello I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva 2010 this is what i get: drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ and i don't have ANY problem with lock files and RXTX in my java software. All i had to do was add this rule to udev: # serial KERNEL=="tty*", GROUP="uucp", MODE="0666" and that was all. Of course my user (metalklesk) is part of uucp group. I did not make /var/lock writable to all users. Greetings ! 2010/2/3 Andy Eskelson > Thanks Steve, > > changing the serial ports back the uucp is not a big problem. I have a > udev rule that can be easily modified already. However I cannot see any > way of dealing with the var/lock problem apart from making it writable to > all. Any thoughts? > > Andy > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > wrote: > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > and is a result of unified udev rules. You can work around this by > > making udev change the group back to uucp until something more > > happens. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > Thanks, > > > > Steve > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > Thanks Daniel, > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > this for other programs for some time. > > > . > > > I don't think that this is the same problem. as far as I can understand > > > things, the lock files are written in var/lock. Previously var/lock and > > > dev/tty-whatever were the same group. Now with var/lock owned by and > with > > > a group of root:root anything other than root cannot create a lock > > > file. Even minicom is broken by this change. > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > Daniel Morales Salas wrote: > > > > > >> Hi > > >> > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > the uucp > > >> group did not work as it used to be in earlier versions of linux > distros, > > >> causing RXTX to not work as non root user. > > >> > > >> The problem appears because the existense of UDEV, now you MUST add a > RULE > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > the > > >> Serial Port. > > >> > > >> To solve the problem, without needing to recompile RXTX, you must add > a rule > > >> to grant permissions (0666) to the group for the device or port (tty*, > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > i > > >> come back home i will give it to you (i am at work now). > > >> > > >> Greetings ! > > >> > > >> 2010/2/3 > > >> > > >> > Hello RXTX group, > > >> > > > >> > I have just joined this group, and this is my first posting. > > >> > I wanted to pass on some information regarding rxtx, so apologies > if > > >> > this has been brought up before. I have searched back through the > > >> > archives but nothing specific came up. > > >> > > > >> > I am not a Java programmer, and I only came across rxtx a few days > ago. > > >> > > > >> > I use a piece of test equipment called a miniVNA > > >> > http://www.miniradiosolutions.com/ > > >> > > > >> > This is a serial USB controlled instrument, and it has control > software > > >> > available for MS windows, and a very old and now non-working Linux > > >> > application. > > >> > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > control the > > >> > miniVNA, obviously this application makes use of rxtx. > > >> > > > >> > The program worked fine on Windows, so I set about installing it > onto > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > running > > >> > fairly easily, sorting out the file locking by adding the uucp group > to > > >> > the users account as suggested (I used the 2.2pre binary files) I > then > > >> > passed the install instructions onto another miniVNA user, who also > uses > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > >> > also having file lock problems, but the uucp fix did not work. > Digging > > >> > into his system I found that there have been some changes in SUSE > 11.2. > > >> > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > >> > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > >> > checked, so: > > >> > > > >> > SUSE 11.1, var/lock is root:uucp > > >> > SUSE 11.2 var/lock is root:root > > >> > > > >> > A search on Google brought up several comments regarding this, and > also > > >> > a bugzilla entry. > > >> > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > >> > > > >> > However from reading the various posts, some of which are in the > bugzilla > > >> > entry, it appears that many distros may be, or have changed to this > > >> > configuration, and this will undoubtedly break several things, rxtx > > >> > included. > > >> > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > with the > > >> > no lock file option during configure, and that solved his problem. > > >> > > > >> > As this issue will probably take some time to get resolved across > all the > > >> > various Linux distros, it might be worth considering changing the > default > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > >> > versions of the lib in the binary archive. > > >> > > > >> > Thanks for your indulgence > > >> > > > >> > Andy > > >> > > > >> > _______________________________________________ > > >> > Rxtx mailing list > > >> > Rxtx at qbang.org > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > >> > > > >> > > >> > > >> > > >> -- > > >> Atte: > > >> Daniel Dario Morales Salas > > >> Ingeniero Civil en Computaci?n e Inform?tica > > >> Tel?fono: 02 684 3417 > > >> Celular: 09 643 1802 > > >> Santiago, Chile > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at qbang.org > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > -- > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > WWW: http://www.sharms.org/blog > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Thu Feb 4 05:31:46 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 12:31:46 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: <20100204123146.6cffeb67@workstation.site> Thank's for the confirmation. Something odd is going on somewhere in SUSE 11.2. I'll have to build up a local SUSE11.2 system to see if I can nail down exactly what is going on. Something is blocking the lockfiles in var/lock. The net is nice, but it's a bit difficult trying to work out what is going on what the machine in question is in Germany and I'm in the UK :-) Andy On Wed, 3 Feb 2010 22:26:38 -0300 Daniel Morales Salas wrote: > Hello > > I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva > 2010 this is what i get: > > drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ > > and i don't have ANY problem with lock files and RXTX in my java software. > All i had to do was add this rule to udev: > > # serial > KERNEL=="tty*", GROUP="uucp", MODE="0666" > > and that was all. Of course my user (metalklesk) is part of uucp group. > I did not make /var/lock writable to all users. > > Greetings ! > > 2010/2/3 Andy Eskelson > > > Thanks Steve, > > > > changing the serial ports back the uucp is not a big problem. I have a > > udev rule that can be easily modified already. However I cannot see any > > way of dealing with the var/lock problem apart from making it writable to > > all. Any thoughts? > > > > Andy > > > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > > wrote: > > > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > > and is a result of unified udev rules. You can work around this by > > > making udev change the group back to uucp until something more > > > happens. > > > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > > > Thanks, > > > > > > Steve > > > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > > Thanks Daniel, > > > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > > this for other programs for some time. > > > > . > > > > I don't think that this is the same problem. as far as I can understand > > > > things, the lock files are written in var/lock. Previously var/lock and > > > > dev/tty-whatever were the same group. Now with var/lock owned by and > > with > > > > a group of root:root anything other than root cannot create a lock > > > > file. Even minicom is broken by this change. > > > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > > Daniel Morales Salas wrote: > > > > > > > >> Hi > > > >> > > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > > the uucp > > > >> group did not work as it used to be in earlier versions of linux > > distros, > > > >> causing RXTX to not work as non root user. > > > >> > > > >> The problem appears because the existense of UDEV, now you MUST add a > > RULE > > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > > the > > > >> Serial Port. > > > >> > > > >> To solve the problem, without needing to recompile RXTX, you must add > > a rule > > > >> to grant permissions (0666) to the group for the device or port (tty*, > > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > > i > > > >> come back home i will give it to you (i am at work now). > > > >> > > > >> Greetings ! > > > >> > > > >> 2010/2/3 > > > >> > > > >> > Hello RXTX group, > > > >> > > > > >> > I have just joined this group, and this is my first posting. > > > >> > I wanted to pass on some information regarding rxtx, so apologies > > if > > > >> > this has been brought up before. I have searched back through the > > > >> > archives but nothing specific came up. > > > >> > > > > >> > I am not a Java programmer, and I only came across rxtx a few days > > ago. > > > >> > > > > >> > I use a piece of test equipment called a miniVNA > > > >> > http://www.miniradiosolutions.com/ > > > >> > > > > >> > This is a serial USB controlled instrument, and it has control > > software > > > >> > available for MS windows, and a very old and now non-working Linux > > > >> > application. > > > >> > > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > > control the > > > >> > miniVNA, obviously this application makes use of rxtx. > > > >> > > > > >> > The program worked fine on Windows, so I set about installing it > > onto > > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > > running > > > >> > fairly easily, sorting out the file locking by adding the uucp group > > to > > > >> > the users account as suggested (I used the 2.2pre binary files) I > > then > > > >> > passed the install instructions onto another miniVNA user, who also > > uses > > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > > >> > also having file lock problems, but the uucp fix did not work. > > Digging > > > >> > into his system I found that there have been some changes in SUSE > > 11.2. > > > >> > > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > > >> > > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > > >> > checked, so: > > > >> > > > > >> > SUSE 11.1, var/lock is root:uucp > > > >> > SUSE 11.2 var/lock is root:root > > > >> > > > > >> > A search on Google brought up several comments regarding this, and > > also > > > >> > a bugzilla entry. > > > >> > > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > >> > > > > >> > However from reading the various posts, some of which are in the > > bugzilla > > > >> > entry, it appears that many distros may be, or have changed to this > > > >> > configuration, and this will undoubtedly break several things, rxtx > > > >> > included. > > > >> > > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > > with the > > > >> > no lock file option during configure, and that solved his problem. > > > >> > > > > >> > As this issue will probably take some time to get resolved across > > all the > > > >> > various Linux distros, it might be worth considering changing the > > default > > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > > >> > versions of the lib in the binary archive. > > > >> > > > > >> > Thanks for your indulgence > > > >> > > > > >> > Andy > > > >> > > > > >> > _______________________________________________ > > > >> > Rxtx mailing list > > > >> > Rxtx at qbang.org > > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > > >> > > > > >> > > > >> > > > >> > > > >> -- > > > >> Atte: > > > >> Daniel Dario Morales Salas > > > >> Ingeniero Civil en Computaci?n e Inform?tica > > > >> Tel?fono: 02 684 3417 > > > >> Celular: 09 643 1802 > > > >> Santiago, Chile > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at qbang.org > > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > > > -- > > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > > > WWW: http://www.sharms.org/blog > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From Bob_Jacobsen at lbl.gov Thu Feb 4 09:26:49 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Thu, 4 Feb 2010 08:26:49 -0800 Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 Message-ID: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're using RXTX-2.2pre2, although it emits the known message about "Version mismatch". WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 After the usual messing around, we've got it working on 11 Windows versions, multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ have things working rarely say so, so I don't know whether anybody has gotten it to work on 10.4 or not. The problem encountered is this: dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib dyld: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib followed by the JVM crashing hard. I've got those dump files if that would help. Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If so, is there a patch I can get and build? Thanks Bob -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From tjarvi at qbang.org Thu Feb 4 14:22:21 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 4 Feb 2010 14:22:21 -0700 (MST) Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 In-Reply-To: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> References: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> Message-ID: On Thu, 4 Feb 2010, Bob Jacobsen wrote: > We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're > using RXTX-2.2pre2, although it emits the known message about "Version > mismatch". > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > > After the usual messing around, we've got it working on 11 Windows versions, > multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with > a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ > have things working rarely say so, so I don't know whether anybody has gotten > it to work on 10.4 or not. > > The problem encountered is this: > > dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > dyld: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > followed by the JVM crashing hard. I've got those dump files if that would > help. > > Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If > so, is there a patch I can get and build? > Hi Bob, I talked to a coworker about the problem you ran into. It appears that it is possible to target 'older' Mac systems through makefile configuration changes. "Configuring a Makefile-Based Project If you have a makefile-based project, you can also take advantage of SDK-based development, by adding the appropriate options to your compile and link commands. Using SDKs in makefile-based projects requires GCC 4.0 or later. To choose an SDK, you use the -isysroot option with the compiler and the -syslibroot option with the linker. Both options require that you specify the full path to the desired SDK directory. To set the Deployment OS version in a makefile, use a makefile variable of the form: ENVP= MACOSX_DEPLOYMENT_TARGET=10.4. To use this variable in your makefile, include it in front of your compile and link commands." http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html Or build on the oldest system you want to support. -- Trent Jarvi tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Thu Feb 4 14:56:19 2010 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Thu, 4 Feb 2010 14:56:19 -0700 Subject: [Rxtx] RXTX on 64 Bit Redhat In-Reply-To: References: <4ec9eab61001281448g3dd84910r867619948a4e0d7a@mail.gmail.com> Message-ID: Trent -- Finally fixed all my build related issues. I ran into another issue. On one of my machines my JDK is returning multiple folders for the "java.ext.dirs" (java.ext.dirs -> /opt/jdk1.6.0_17/jre/lib/ext:/usr/java/packages/lib/ext) system property. As a result my JVM wasn't able to detect the gnu.io.rxtx.properties. I am attaching a patch for RXTXCommDriver.java file to check for multiple locations. Also i have to assign permission 660 to all my dev ports to be located by RXTX. Pawan ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 5:12 PM To: Trent Jarvi Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Here is the error i get when i build the src from release-2-1-7 -bash-3.2$ make ( \ \ cd i686-pc-linux-gnu; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/ jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I/opt/jav a1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec - c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialImp.lo;\ if [ "Serial" = "Serial" ]; then \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I /opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_tim espec -c /home/jb_stg/rxtx/rxtx-devel/./src/fuserImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ else \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo; \ fi; \ ) gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/inclu de -I/opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need _timespec -c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -fPIC -DPIC -o /hom e/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/.libs/SerialImp.o /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:25:29: error: gnu_io_RXTXPort.h: No such file or directory In file included from /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:113: /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:91: error: expected specifier-qua lifier-list before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'jobject' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:408: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:409: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:410: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:411: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:415: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:416: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:417: error: expected '=', ',', '; ', 'asm' or '__attribute__' before 'is_interrupted' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:418: error: expected declaration specifiers or '...' before 'jint' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:424: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:441: error: expected ')' before ' *' token ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 4:57 PM To: Santosh Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Santosh -- Thank you. That fixed the issue. All -- What CVS branch or release should i use to get the latest RXTX src code. Pawan ________________________________ From: Santosh [mailto:santosh.ry at gmail.com] Sent: Thursday, January 28, 2010 3:49 PM To: Kharbanda, Pawan Cc: Trent Jarvi; rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat error "./configure: /bin/sh^M: bad interpreter: No such file or directory". I think you need to run dos2unix on script files before compiling. Thanks, Santosh On Thu, Jan 28, 2010 at 5:33 PM, Kharbanda, Pawan > wrote: Trent -- We are upgrading our exisiting OS and JDK on a project that rely heavily on RXTX api's. We are now using JDK1.6 32 bit (build 1.6.0_17-b04) and RedHat 5 on a 64 bit machine. Linux tocrhstg02.dot.state.co.us 2.6.18-164.6.1.el5 #1 SMP Tue Oct 27 11:30:06 EDT 2009 i686 i686 i386 GNU/Linux Red Hat Enterprise Linux Server release 5.4 (Tikanga) I tried to run version 2.1.7 r2 on it but not able to see any of my Digi ports I was able to access only /dev/ttyS0 (physical ports). Not sure if the problem is with the Digi driver or RXTX. I tried to open a Digi port with minicom and it worked fine. I also tried to get latest from CVS (rxtx-devel) and when I do "configure" I see this error "./configure: /bin/sh^M: bad interpreter: No such file or directory". Can someone please help me with this? Thanks for the help. Pawan _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch.txt URL: From juan.vicente.l.g at gmail.com Sat Feb 13 04:44:17 2010 From: juan.vicente.l.g at gmail.com (Juan Vicente Lopez Gutierrez) Date: Sat, 13 Feb 2010 12:44:17 +0100 Subject: [Rxtx] RXTX in macmini OSX 10.5 Message-ID: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> Hello. My name is Juanvi and I'm from Spain. I tried to launch a software created by me in the library CXR java to send information through the serial port and I can not make it work. In windows if I've done but not mac. I have a mac mini with OSX 10.5 and have read in the list of web mail that you CXR if you have managed to make it work on that operating system. I need you help me please. Do I make the mistake that shows me java: run: Stable Library =============================== Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 gnu.io.PortInUseException: Unknow Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:26) at TwoWatSerialComm.main(TwoWaySerialComm.java:106) Experimental: JNI_OnLoad called. GENERACION CORRECTA (total time: 0 seconds) I do not have permission to access the serial port, do not know. Os agradeceria much to sit down. A greeting and thanks. Pardon my English. Juanvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From juan.vicente.l.g at gmail.com Sat Feb 13 14:39:41 2010 From: juan.vicente.l.g at gmail.com (Juan Vicente Lopez Gutierrez) Date: Sat, 13 Feb 2010 22:39:41 +0100 Subject: [Rxtx] Fwd: RXTX in macmini OSX 10.5 In-Reply-To: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> References: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> Message-ID: <29405e5c1002131339m2059d169sdc8549ed9706a1af@mail.gmail.com> ---------- Forwarded message ---------- From: Juan Vicente Lopez Gutierrez Date: 2010/2/13 Subject: RXTX in macmini OSX 10.5 To: rxtx at qbang.org Hello. My name is Juanvi and I'm from Spain. I tried to launch a software created by me in the library CXR java to send information through the serial port and I can not make it work. In windows if I've done but not mac. I have a mac mini with OSX 10.5 and have read in the list of web mail that you CXR if you have managed to make it work on that operating system. I need you help me please. Do I make the mistake that shows me java: run: Stable Library =============================== Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 gnu.io.PortInUseException: Unknow Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:26) at TwoWatSerialComm.main(TwoWaySerialComm.java:106) Experimental: JNI_OnLoad called. GENERACION CORRECTA (total time: 0 seconds) I do not have permission to access the serial port, do not know. Os agradeceria much to sit down. A greeting and thanks. Pardon my English. Juanvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 01:02:21 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 13:32:21 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> My serial port driver(apparently) does not support receive timeout.I registered an event listener for DATA_AVAILABLE. However, the control never seems to come out of the 'while' loop.Shouldn't the InputStream.read return a '-1' immediately if no data is available (this seems to be the default operation)? This was tried on a x86 Linux desktop using rxtx-2.1-7 I've added the snippet for clarity: /******************************************************************************************************************************************************************************/ mySerialPort.enableReceiveThreshold(2000);//Trying to set a time limit for read calls System.out.println(mySerialPort.isReceiveTimeoutEnabled()); // I get FALSE, so its not supported on hardware. mySerialPort.addEventListener(this); mySerialPort.notifyOnDataAvailable(true);//register a event with //my SerialEvent listener implementation: public void serialEvent(SerialPortEvent arg0) { int newData=0; switch(arg0.getEventType()){ case SerialPortEvent.DATA_AVAILABLE: while (newData != -1) { try { newData = is.read();//This should eventually return a -1 if no data is available within a timeout.PROBLEM!! System.out.println("Got a byte from port:"+newData); if (newData == -1) { break; } } catch (IOException ex) { System.err.println(ex); return; } } break; } return; } /******************************************************************************************************************************************************************************/ Thanks and regards, Ravi From michael.erskine at ketech.com Wed Feb 3 02:26:50 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 09:26:50 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From michael.erskine at ketech.com Wed Feb 3 05:03:30 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 12:03:30 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > Michael Erskine > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > > Your event handler should handle the event and return immediately so that its > controlling thread can handle other events. I recommend a single read in the > following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) > reads all available bytes up to the size of the buffer returning the number of > bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } After posting this I considered the glaring possibility of the rawbuf read buffer being too small to receive all the available bytes and perhaps skipping data: after all, I'm guessing that is why we see so many posts asking for help with blocking implementations of read event handlers looping on "while(bytes are available)". I've spent this morning writing an extensive multi-threaded unit test suite that includes tests with a tiny buffer compared to the amount of data available and found that no data was being skipped. I now want to know why! The SerialPortEvent.DATA_AVAILABLE event must be being fired again if there is more data available on the input stream. If that is the case then it should be heavily documented with good examples in the wiki to avoid the types of developer anguish we see so regularly. BTW: I'm not at liberty to post the JUnit tests as they use my company's unit test suite framework. Regards, Michael Erskine. From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 06:18:04 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 18:48:04 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Hello Michael, I tried out your suggestion but the problem is that the read(rawbuf) blocks until the entire length of the rawbuf array has been read (blocking). I cannot decide on a reasonable size of the array because it varies from 2 bytes to as much as 50 byes (i'm communicating with a modem,each response is of a different length), which is why i wanted to use non blocking calls. But on a side note, read(byte[]) in turn calls the read() in a loop.In the native C function, the read is supposed to return a -1 upon timeout.But my driver does not support timeout.The default timeout value is zero and the linux select call upon zero time out causes an infinite wait.What am i missing...... Thanks and regards, Ravi Date: Wed, 3 Feb 2010 09:26:50 +0000 From: Michael Erskine To: "rxtx at qbang.org" Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: Content-Type: text/plain; charset="us-ascii" > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From m.kirkland at comcast.net Wed Feb 3 06:46:03 2010 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 3 Feb 2010 05:46:03 -0800 Subject: [Rxtx] One port blocking another port In-Reply-To: References: Message-ID: <68768633814F4D7D86761D34F0764FE0@bengal.net> It turns out this is caused by having the RTS/CTS flow control turned on and me not providing a true on the RTS pin. Somehow it seems the port timing out on a read allows the write to proceed. This is not an issue for my application but I wonder if the write should not proceed until the RTS pin is true even if a read times out. mk -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Monday, January 25, 2010 7:48 PM To: Mike Kirkland Cc: rxtx at qbang.org Subject: Re: [Rxtx] One port blocking another port On Mon, 25 Jan 2010, Mike Kirkland wrote: > > Hi All, > > ? > > I have a program that reads from one com port and writes to another com > port. It also does the same thing in reverse (reads from the second com port > and writes to the first one. It basically ties two com ports together. > > ? > > One port is very chatty and has a consent stream of data. The other port has > very little data. > > ? > > Both ports use a 5000 ms (5 second) time out. > > ? > > The issue I am having is that is appears that the first port?s write to the > second port is blocked while the second port is waiting for input. The first > port?s write proceeds only after the second port has timed out. > > ? > > I suppose I could have something twisted around in my code but I was > wondering if this is a know issue? > Hi Kirk, I've not seen a report like this. Perhaps some simple reproduction code will reveal a problem on your end or help us identify a problem in rxtx. I think there are several users doing multiport communication. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Wed Feb 3 07:03:58 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:03:58 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Message-ID: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> 2010/2/3 Ravishankar N > Hello Michael, > [..] > But on a side note, read(byte[]) in turn calls the read() in a loop.In the > native C function, the read is supposed to return a -1 upon timeout.But my > driver > does not support timeout.The default timeout value is zero and the linux > select call upon zero time out causes an infinite wait.What am i > missing...... > > When I have tested RXTX between platforms, I have observed "hangup" inside JNI driver when no data in Linux, is normal thing. Solution was setting the timeout for RXTX when no data from JNI driver. Something like that: commPort.enableReceiveTimeout(10); And it works perfect.... The only difference is that I am NOT using events - I am using continous read in separate thread and if data is available, is parsed and transferred to application using exception. Regards Mariusz > Thanks and regards, > Ravi > > Date: Wed, 3 Feb 2010 09:26:50 +0000 > From: Michael Erskine > To: "rxtx at qbang.org" > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > Message-ID: > > > Content-Type: text/plain; charset="us-ascii" > > > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of > > Ravishankar N > > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > > > My serial port driver(apparently) does not support receive timeout.I > > registered an event listener for DATA_AVAILABLE. However, the control > never > > seems to come out of the 'while' loop.Shouldn't the > > InputStream.read return a '-1' immediately if no data is available (this > seems > > to be the default operation)? > > Your event handler should handle the event and return immediately so that > its controlling thread can handle other events. I recommend a single read in > the following manner: rawbuf is a byte[] of "reasonable" size and the > read(byte[]) reads all available bytes up to the size of the buffer > returning the number of bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } > > This style of reading has worked for me with RXTX on Linux and Windows XP > for a good few years now in railway industry communications systems. Any > timeouts (largely unnecessary in my applications) can be handled elsewhere, > usually at a higher layer. > > Regards, > Michael Erskine. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Feb 3 07:22:55 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 3 Feb 2010 09:22:55 -0500 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: I'm guessing that this is driver specific. I recently had to support a select()/poll() infrastructure for a linux serial DD, its certainly non trivial to support async IO, so I suspect the problem in this case has to do with missing poll infrastructure in the device driver. This also has to coupled with special open flags for the device (which is within the rxtx code) The key routines within a 2.6 kernel linux device driver are shown below (if you have access to it for your particular device) are indicated below (here is a snippet from my device driver c code that supports polling/select). User space code to test this shown below also, note that the device needs to be opened with the O_NONBLOCK option to support the select/poll api // device driver code ..... /* * File operations supported by this driver. */ static struct file_operations iop_fops = { .owner = THIS_MODULE, .check_flags= iop_check_flags, .ioctl = iop_ioctl, .open = iop_open, .poll = iop_poll, // SUPPORT FOR SELECT/POLL infrastructure .read = iop_read, .release = iop_release, .write = iop_write, }; /** * Select/poll/epoll infrastructure. * * @param file * @param wait * * @return */ static unsigned int iop_poll(struct file *filp, poll_table *wait) { struct iop_device *devp = (struct iop_device *)filp->private_data; // the poll_table wait arg is an opaque pointer poll_wait(filp, &devp->readq, wait); // return from poll indicating whether we have read/write data unsigned int mask = 0; if (kfifo_len(devp->rx_fifo)) { mask |= (POLLIN | POLLRDNORM); } // @JC We don't do select on write yet // if (kfifo_len(devp->tx_fifo)) { // mask |= (POLLOUT | POLLWRNORM); // } // Only print out while debugging // if (mask != 0) { // printk (KERN_INFO "%s: [%04x]\n", __FUNCTION__, mask); // } return mask; } /** * device driver blocking and non blocking read function. This * function reads the requested number of bytes from the read * kfifo blocking as required. * * @param filp * @param buf * @param count * @param f_pos * * @return */ static ssize_t iop_read(struct file *filp, char __user *buf, size_t count, loff_t * ppos) { // access appropriate device struct struct iop_device *devp = (struct iop_device *) filp->private_data; ssize_t retval; // support non blocking mode (default) by checking if the kfifo is empty first if ((kfifo_len(devp->rx_fifo)==0) && (filp->f_flags & O_NONBLOCK)) { return -EAGAIN; } // wait for rx_fifo to receive data via receive interrupts retval = wait_event_interruptible(devp->readq, kfifo_len(devp->rx_fifo) != 0); // check for some error condition if (retval) { printk (KERN_ERR "%s: wait_event_interruptible returned[%d]\n", __FUNCTION__, retval); return retval; } // copy max requested bytes from rx_fifo to device buffer // this may still leave bytes in the kfifo for a subsequent read // if we are reading in a loop retval = kfifo_get(devp->rx_fifo, devp->rxbuf, count); // printk (KERN_INFO "%s: [%d] byte(s)\n", __FUNCTION__, retval); if (copy_to_user(buf, devp->rxbuf, retval)) { printk (KERN_ERR "%s: problem copying rx_fifo data to user buffer\n", __FUNCTION__); return -EFAULT; } return retval; } // a selection of my user space code reading via select()/poll()..... // user space open code iop_fd = ::open( deviceName.data(), O_RDWR | O_NONBLOCK); while ((bytes_to_expect - bytes_read) > 0) { // must reinitialize these between select calls fd_set readfds; FD_ZERO( &readfds ); FD_SET( iop_fd, &readfds ); // 1s sec read polling timeout struct timeval timeout; timeout.tv_sec = 1; timeout.tv_usec = 0; int rc = select( FD_SETSIZE, &readfds, NULL, NULL, &timeout ); // read from file when descriptor // indicates data available without blocking if ((rc > 0) && FD_ISSET(iop_fd, &readfds)) { // read into the appropriate offset within the rx_buf int temp = read(iop_fd, rx_buf + bytes_read, bytes_to_expect - bytes_read); if (!temp) { printf("EOF detected with %d bytes expected\n", bytes_to_expect - bytes_read); } else { bytes_read += temp; } } else if (rc < 0){ printf("%s: select on [%s], bytes_read[%d], errno=%d\n", __FUNCTION__, thread_args->device, bytes_read, errno); } else { printf("%s: select on [%s], bytes_read[%d], timeout\n", __FUNCTION__, thread_args->device, bytes_read); } } On Wed, Feb 3, 2010 at 9:03 AM, Mariusz Dec wrote: > > > 2010/2/3 Ravishankar N > >> Hello Michael, >> [..] >> >> But on a side note, read(byte[]) in turn calls the read() in a loop.In the >> native C function, the read is supposed to return a -1 upon timeout.But my >> driver >> does not support timeout.The default timeout value is zero and the linux >> select call upon zero time out causes an infinite wait.What am i >> missing...... >> >> > When I have tested RXTX between platforms, I have observed "hangup" inside > JNI driver when no data in Linux, is normal thing. > > Solution was setting the timeout for RXTX when no data from JNI driver. > > Something like that: > > commPort.enableReceiveTimeout(10); > > And it works perfect.... > > The only difference is that I am NOT using events - I am using continous > read in separate thread and if data is available, is parsed and transferred > to application using exception. > > Regards > Mariusz > > > >> Thanks and regards, >> Ravi >> >> Date: Wed, 3 Feb 2010 09:26:50 +0000 >> From: Michael Erskine >> To: "rxtx at qbang.org" >> Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? >> Message-ID: >> >> >> Content-Type: text/plain; charset="us-ascii" >> >> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >> Of >> > Ravishankar N >> > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? >> > >> > My serial port driver(apparently) does not support receive timeout.I >> > registered an event listener for DATA_AVAILABLE. However, the control >> never >> > seems to come out of the 'while' loop.Shouldn't the >> > InputStream.read return a '-1' immediately if no data is available (this >> seems >> > to be the default operation)? >> >> Your event handler should handle the event and return immediately so that >> its controlling thread can handle other events. I recommend a single read in >> the following manner: rawbuf is a byte[] of "reasonable" size and the >> read(byte[]) reads all available bytes up to the size of the buffer >> returning the number of bytes actually read... >> >> case SerialPortEvent.DATA_AVAILABLE: >> try { >> int i = is.read(rawbuf); >> if (i == -1) { >> << process EOF condition - should never happen >> >> return; >> } >> << process bytes (rawbuf, i); >> >> return; >> } catch (IOException e) { >> << promptly deal with exception >> >> return; >> } >> >> This style of reading has worked for me with RXTX on Linux and Windows XP >> for a good few years now in railway industry communications systems. Any >> timeouts (largely unnecessary in my applications) can be handled elsewhere, >> usually at a higher layer. >> >> Regards, >> Michael Erskine. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Feb 3 07:33:27 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:33:27 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: <73a89f361002030633j682610afia48dc7accd8e049b@mail.gmail.com> 2010/2/3 John Coffey > I'm guessing that this is driver specific. I recently had to support a > select()/poll() infrastructure for a linux serial DD, its certainly non > trivial to support async IO, so I suspect the problem in this case has to do > with missing poll infrastructure in the device driver. This also has to > coupled with special open flags for the device (which is within the rxtx > code) > > Yes, you are right, it may be driver specific, but in my case I haven't changed blocking JNI driver. I have added ONLY one call to RXTX method mentioned in my previous post and blocking (as seen as from Java app) gone out... Maybe this is not elegant, but works without problem in my app. I am using only FTDI chips and their drivers from couple of years and maybe this is the kind of the way to have no many problems with serial as well? Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From andyrxtx at g0poy.co.uk Wed Feb 3 11:09:04 2010 From: andyrxtx at g0poy.co.uk (andyrxtx at g0poy.co.uk) Date: Wed, 3 Feb 2010 18:09:04 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes Message-ID: <20100203180904.164f24dd@workstation.site> ?Hello RXTX group, I have just joined this group, and this is my first posting. I wanted to pass on some information regarding rxtx, so apologies if this has been brought up before. I have searched back through the archives but nothing specific came up. I am not a Java programmer, and I only came across rxtx a few days ago. I use a piece of test equipment called a miniVNA http://www.miniradiosolutions.com/ This is a serial USB controlled instrument, and it has control software available for MS windows, and a very old and now non-working Linux application. A few days ago Dietmar, DL2SBA released a Java application to control the miniVNA, obviously this application makes use of rxtx. The program worked fine on Windows, so I set about installing it onto Linux. I use SUSE11.1 After a few false starts, I got the system running fairly easily, sorting out the file locking by adding the uucp group to the users account as suggested (I used the 2.2pre binary files) I then passed the install instructions onto another miniVNA user, who also uses SUSE, but he ran into problems. To cut a long story short, he was also having file lock problems, but the uucp fix did not work. Digging into his system I found that there have been some changes in SUSE 11.2. tty ports are now assigned to the dialout group rather than uucp. A hint in the rxtx INSTALL file, suggested that var/lock needs to be checked, so: SUSE 11.1, var/lock is root:uucp SUSE 11.2 var/lock is root:root A search on Google brought up several comments regarding this, and also a bugzilla entry. https://bugzilla.novell.com/show_bug.cgi?id=552095 However from reading the various posts, some of which are in the bugzilla entry, it appears that many distros may be, or have changed to this configuration, and this will undoubtedly break several things, rxtx included. I solved my fellow SUSE users problem by compiling the rxtx libs with the no lock file option during configure, and that solved his problem. As this issue will probably take some time to get resolved across all the various Linux distros, it might be worth considering changing the default on the Linux build of rxtx not to use lockfiles, or provide the two versions of the lib in the binary archive. Thanks for your indulgence Andy From damorales at gmail.com Wed Feb 3 11:33:23 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 15:33:23 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203180904.164f24dd@workstation.site> References: <20100203180904.164f24dd@workstation.site> Message-ID: Hi I had the same problem in Mandriva 2010 and yes, adding the user to the uucp group did not work as it used to be in earlier versions of linux distros, causing RXTX to not work as non root user. The problem appears because the existense of UDEV, now you MUST add a RULE so the group (uucp or whatever) have access (Read, Write, Execute) to the Serial Port. To solve the problem, without needing to recompile RXTX, you must add a rule to grant permissions (0666) to the group for the device or port (tty*, ttyUSB*, etc). I do not remember now what is the line i added but when i come back home i will give it to you (i am at work now). Greetings ! 2010/2/3 > Hello RXTX group, > > I have just joined this group, and this is my first posting. > I wanted to pass on some information regarding rxtx, so apologies if > this has been brought up before. I have searched back through the > archives but nothing specific came up. > > I am not a Java programmer, and I only came across rxtx a few days ago. > > I use a piece of test equipment called a miniVNA > http://www.miniradiosolutions.com/ > > This is a serial USB controlled instrument, and it has control software > available for MS windows, and a very old and now non-working Linux > application. > > A few days ago Dietmar, DL2SBA released a Java application to control the > miniVNA, obviously this application makes use of rxtx. > > The program worked fine on Windows, so I set about installing it onto > Linux. I use SUSE11.1 After a few false starts, I got the system running > fairly easily, sorting out the file locking by adding the uucp group to > the users account as suggested (I used the 2.2pre binary files) I then > passed the install instructions onto another miniVNA user, who also uses > SUSE, but he ran into problems. To cut a long story short, he was > also having file lock problems, but the uucp fix did not work. Digging > into his system I found that there have been some changes in SUSE 11.2. > > tty ports are now assigned to the dialout group rather than uucp. > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > checked, so: > > SUSE 11.1, var/lock is root:uucp > SUSE 11.2 var/lock is root:root > > A search on Google brought up several comments regarding this, and also > a bugzilla entry. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > However from reading the various posts, some of which are in the bugzilla > entry, it appears that many distros may be, or have changed to this > configuration, and this will undoubtedly break several things, rxtx > included. > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > no lock file option during configure, and that solved his problem. > > As this issue will probably take some time to get resolved across all the > various Linux distros, it might be worth considering changing the default > on the Linux build of rxtx not to use lockfiles, or provide the two > versions of the lib in the binary archive. > > Thanks for your indulgence > > Andy > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Wed Feb 3 12:07:02 2010 From: andy at g0poy.com (Andy Eskelson) Date: Wed, 3 Feb 2010 19:07:02 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> Message-ID: <20100203190702.1b0e7015@workstation.site> Thanks Daniel, I am aware of the permissions problem, I have had a udev rules to solve this for other programs for some time. . I don't think that this is the same problem. as far as I can understand things, the lock files are written in var/lock. Previously var/lock and dev/tty-whatever were the same group. Now with var/lock owned by and with a group of root:root anything other than root cannot create a lock file. Even minicom is broken by this change. This change is going to have quite a few knock-on effects I think. Andy On Wed, 3 Feb 2010 15:33:23 -0300 Daniel Morales Salas wrote: > Hi > > I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > group did not work as it used to be in earlier versions of linux distros, > causing RXTX to not work as non root user. > > The problem appears because the existense of UDEV, now you MUST add a RULE > so the group (uucp or whatever) have access (Read, Write, Execute) to the > Serial Port. > > To solve the problem, without needing to recompile RXTX, you must add a rule > to grant permissions (0666) to the group for the device or port (tty*, > ttyUSB*, etc). I do not remember now what is the line i added but when i > come back home i will give it to you (i am at work now). > > Greetings ! > > 2010/2/3 > > > Hello RXTX group, > > > > I have just joined this group, and this is my first posting. > > I wanted to pass on some information regarding rxtx, so apologies if > > this has been brought up before. I have searched back through the > > archives but nothing specific came up. > > > > I am not a Java programmer, and I only came across rxtx a few days ago. > > > > I use a piece of test equipment called a miniVNA > > http://www.miniradiosolutions.com/ > > > > This is a serial USB controlled instrument, and it has control software > > available for MS windows, and a very old and now non-working Linux > > application. > > > > A few days ago Dietmar, DL2SBA released a Java application to control the > > miniVNA, obviously this application makes use of rxtx. > > > > The program worked fine on Windows, so I set about installing it onto > > Linux. I use SUSE11.1 After a few false starts, I got the system running > > fairly easily, sorting out the file locking by adding the uucp group to > > the users account as suggested (I used the 2.2pre binary files) I then > > passed the install instructions onto another miniVNA user, who also uses > > SUSE, but he ran into problems. To cut a long story short, he was > > also having file lock problems, but the uucp fix did not work. Digging > > into his system I found that there have been some changes in SUSE 11.2. > > > > tty ports are now assigned to the dialout group rather than uucp. > > > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > checked, so: > > > > SUSE 11.1, var/lock is root:uucp > > SUSE 11.2 var/lock is root:root > > > > A search on Google brought up several comments regarding this, and also > > a bugzilla entry. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > However from reading the various posts, some of which are in the bugzilla > > entry, it appears that many distros may be, or have changed to this > > configuration, and this will undoubtedly break several things, rxtx > > included. > > > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > > no lock file option during configure, and that solved his problem. > > > > As this issue will probably take some time to get resolved across all the > > various Linux distros, it might be worth considering changing the default > > on the Linux build of rxtx not to use lockfiles, or provide the two > > versions of the lib in the binary archive. > > > > Thanks for your indulgence > > > > Andy > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From thisdyingdream at gmail.com Wed Feb 3 12:32:35 2010 From: thisdyingdream at gmail.com (Steven Harms) Date: Wed, 3 Feb 2010 14:32:35 -0500 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203190702.1b0e7015@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: This is currently a bug in OpenSUSE that affects more than just rxtx, and is a result of unified udev rules. You can work around this by making udev change the group back to uucp until something more happens. https://bugzilla.novell.com/show_bug.cgi?id=552095 Thanks, Steve On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > Thanks Daniel, > > I am aware of the permissions problem, I have had a udev rules to solve > this for other programs for some time. > . > I don't think that this is the same problem. as far as I can understand > things, the lock files are written in var/lock. Previously var/lock and > dev/tty-whatever were the same group. Now with var/lock owned by and with > a group of root:root anything other than root cannot create a lock > file. Even minicom is broken by this change. > > This change is going to have quite a few knock-on effects I think. > > > Andy > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > Daniel Morales Salas wrote: > >> Hi >> >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp >> group did not work as it used to be in earlier versions of linux distros, >> causing RXTX to not work as non root user. >> >> The problem appears because the existense of UDEV, now you MUST add a RULE >> so the group (uucp or whatever) have access (Read, Write, Execute) to the >> Serial Port. >> >> To solve the problem, without needing to recompile RXTX, you must add a rule >> to grant permissions (0666) to the group for the device or port (tty*, >> ttyUSB*, etc). I do not remember now what is the line i added but when i >> come back home i will give it to you (i am at work now). >> >> Greetings ! >> >> 2010/2/3 >> >> > Hello RXTX group, >> > >> > I have just joined this group, and this is my first posting. >> > I wanted to pass on ?some information regarding rxtx, so apologies if >> > this has been brought up before. I have searched back through the >> > archives but nothing specific came up. >> > >> > I am not a Java programmer, and I only came across rxtx a few days ago. >> > >> > I use a piece of test equipment called a miniVNA >> > http://www.miniradiosolutions.com/ >> > >> > This is a serial USB controlled instrument, and it has control software >> > available for MS windows, and a very old and now non-working Linux >> > application. >> > >> > A few days ago Dietmar, DL2SBA released a Java application to control the >> > miniVNA, obviously this application makes use of rxtx. >> > >> > The program worked fine on Windows, so I set about installing it onto >> > Linux. I use SUSE11.1 After a few false starts, I got the system running >> > fairly easily, sorting out the file locking by adding the uucp group to >> > the users account as suggested (I used the 2.2pre binary files) I then >> > passed the install instructions onto another miniVNA user, who also uses >> > SUSE, but he ran into problems. To cut a long story short, he was >> > also having file lock problems, but the uucp fix did not work. Digging >> > into his system I found that there have been some changes in SUSE 11.2. >> > >> > tty ports are now assigned to the dialout group rather than uucp. >> > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be >> > checked, so: >> > >> > SUSE 11.1, var/lock is root:uucp >> > SUSE 11.2 var/lock is root:root >> > >> > A search on Google brought up several comments regarding this, and also >> > a ?bugzilla entry. >> > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 >> > >> > However from reading the various posts, some of which are in the bugzilla >> > entry, it appears that many distros may be, or have changed to this >> > configuration, and this will undoubtedly break several things, rxtx >> > included. >> > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the >> > no lock file option during configure, and that solved his problem. >> > >> > As this issue will probably take some time to get resolved across all the >> > various Linux distros, it might be worth considering changing the default >> > on the Linux build of rxtx not to use lockfiles, or provide the two >> > versions of the lib in the binary archive. >> > >> > Thanks for your indulgence >> > >> > Andy >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> >> >> >> -- >> Atte: >> Daniel Dario Morales Salas >> Ingeniero Civil en Computaci?n e Inform?tica >> Tel?fono: 02 684 3417 >> Celular: 09 643 1802 >> Santiago, Chile > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 WWW: http://www.sharms.org/blog From andy at g0poy.com Wed Feb 3 17:58:29 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 00:58:29 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: <20100204005829.7dc944e1@workstation.site> Thanks Steve, changing the serial ports back the uucp is not a big problem. I have a udev rule that can be easily modified already. However I cannot see any way of dealing with the var/lock problem apart from making it writable to all. Any thoughts? Andy On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms wrote: > This is currently a bug in OpenSUSE that affects more than just rxtx, > and is a result of unified udev rules. You can work around this by > making udev change the group back to uucp until something more > happens. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > Thanks, > > Steve > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > Thanks Daniel, > > > > I am aware of the permissions problem, I have had a udev rules to solve > > this for other programs for some time. > > . > > I don't think that this is the same problem. as far as I can understand > > things, the lock files are written in var/lock. Previously var/lock and > > dev/tty-whatever were the same group. Now with var/lock owned by and with > > a group of root:root anything other than root cannot create a lock > > file. Even minicom is broken by this change. > > > > This change is going to have quite a few knock-on effects I think. > > > > > > Andy > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > Daniel Morales Salas wrote: > > > >> Hi > >> > >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > >> group did not work as it used to be in earlier versions of linux distros, > >> causing RXTX to not work as non root user. > >> > >> The problem appears because the existense of UDEV, now you MUST add a RULE > >> so the group (uucp or whatever) have access (Read, Write, Execute) to the > >> Serial Port. > >> > >> To solve the problem, without needing to recompile RXTX, you must add a rule > >> to grant permissions (0666) to the group for the device or port (tty*, > >> ttyUSB*, etc). I do not remember now what is the line i added but when i > >> come back home i will give it to you (i am at work now). > >> > >> Greetings ! > >> > >> 2010/2/3 > >> > >> > Hello RXTX group, > >> > > >> > I have just joined this group, and this is my first posting. > >> > I wanted to pass on ?some information regarding rxtx, so apologies if > >> > this has been brought up before. I have searched back through the > >> > archives but nothing specific came up. > >> > > >> > I am not a Java programmer, and I only came across rxtx a few days ago. > >> > > >> > I use a piece of test equipment called a miniVNA > >> > http://www.miniradiosolutions.com/ > >> > > >> > This is a serial USB controlled instrument, and it has control software > >> > available for MS windows, and a very old and now non-working Linux > >> > application. > >> > > >> > A few days ago Dietmar, DL2SBA released a Java application to control the > >> > miniVNA, obviously this application makes use of rxtx. > >> > > >> > The program worked fine on Windows, so I set about installing it onto > >> > Linux. I use SUSE11.1 After a few false starts, I got the system running > >> > fairly easily, sorting out the file locking by adding the uucp group to > >> > the users account as suggested (I used the 2.2pre binary files) I then > >> > passed the install instructions onto another miniVNA user, who also uses > >> > SUSE, but he ran into problems. To cut a long story short, he was > >> > also having file lock problems, but the uucp fix did not work. Digging > >> > into his system I found that there have been some changes in SUSE 11.2. > >> > > >> > tty ports are now assigned to the dialout group rather than uucp. > >> > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > >> > checked, so: > >> > > >> > SUSE 11.1, var/lock is root:uucp > >> > SUSE 11.2 var/lock is root:root > >> > > >> > A search on Google brought up several comments regarding this, and also > >> > a ?bugzilla entry. > >> > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > >> > > >> > However from reading the various posts, some of which are in the bugzilla > >> > entry, it appears that many distros may be, or have changed to this > >> > configuration, and this will undoubtedly break several things, rxtx > >> > included. > >> > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the > >> > no lock file option during configure, and that solved his problem. > >> > > >> > As this issue will probably take some time to get resolved across all the > >> > various Linux distros, it might be worth considering changing the default > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > >> > versions of the lib in the binary archive. > >> > > >> > Thanks for your indulgence > >> > > >> > Andy > >> > > >> > _______________________________________________ > >> > Rxtx mailing list > >> > Rxtx at qbang.org > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > >> > >> > >> > >> -- > >> Atte: > >> Daniel Dario Morales Salas > >> Ingeniero Civil en Computaci?n e Inform?tica > >> Tel?fono: 02 684 3417 > >> Celular: 09 643 1802 > >> Santiago, Chile > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > WWW: http://www.sharms.org/blog From damorales at gmail.com Wed Feb 3 18:26:38 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 22:26:38 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100204005829.7dc944e1@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: Hello I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva 2010 this is what i get: drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ and i don't have ANY problem with lock files and RXTX in my java software. All i had to do was add this rule to udev: # serial KERNEL=="tty*", GROUP="uucp", MODE="0666" and that was all. Of course my user (metalklesk) is part of uucp group. I did not make /var/lock writable to all users. Greetings ! 2010/2/3 Andy Eskelson > Thanks Steve, > > changing the serial ports back the uucp is not a big problem. I have a > udev rule that can be easily modified already. However I cannot see any > way of dealing with the var/lock problem apart from making it writable to > all. Any thoughts? > > Andy > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > wrote: > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > and is a result of unified udev rules. You can work around this by > > making udev change the group back to uucp until something more > > happens. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > Thanks, > > > > Steve > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > Thanks Daniel, > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > this for other programs for some time. > > > . > > > I don't think that this is the same problem. as far as I can understand > > > things, the lock files are written in var/lock. Previously var/lock and > > > dev/tty-whatever were the same group. Now with var/lock owned by and > with > > > a group of root:root anything other than root cannot create a lock > > > file. Even minicom is broken by this change. > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > Daniel Morales Salas wrote: > > > > > >> Hi > > >> > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > the uucp > > >> group did not work as it used to be in earlier versions of linux > distros, > > >> causing RXTX to not work as non root user. > > >> > > >> The problem appears because the existense of UDEV, now you MUST add a > RULE > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > the > > >> Serial Port. > > >> > > >> To solve the problem, without needing to recompile RXTX, you must add > a rule > > >> to grant permissions (0666) to the group for the device or port (tty*, > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > i > > >> come back home i will give it to you (i am at work now). > > >> > > >> Greetings ! > > >> > > >> 2010/2/3 > > >> > > >> > Hello RXTX group, > > >> > > > >> > I have just joined this group, and this is my first posting. > > >> > I wanted to pass on some information regarding rxtx, so apologies > if > > >> > this has been brought up before. I have searched back through the > > >> > archives but nothing specific came up. > > >> > > > >> > I am not a Java programmer, and I only came across rxtx a few days > ago. > > >> > > > >> > I use a piece of test equipment called a miniVNA > > >> > http://www.miniradiosolutions.com/ > > >> > > > >> > This is a serial USB controlled instrument, and it has control > software > > >> > available for MS windows, and a very old and now non-working Linux > > >> > application. > > >> > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > control the > > >> > miniVNA, obviously this application makes use of rxtx. > > >> > > > >> > The program worked fine on Windows, so I set about installing it > onto > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > running > > >> > fairly easily, sorting out the file locking by adding the uucp group > to > > >> > the users account as suggested (I used the 2.2pre binary files) I > then > > >> > passed the install instructions onto another miniVNA user, who also > uses > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > >> > also having file lock problems, but the uucp fix did not work. > Digging > > >> > into his system I found that there have been some changes in SUSE > 11.2. > > >> > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > >> > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > >> > checked, so: > > >> > > > >> > SUSE 11.1, var/lock is root:uucp > > >> > SUSE 11.2 var/lock is root:root > > >> > > > >> > A search on Google brought up several comments regarding this, and > also > > >> > a bugzilla entry. > > >> > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > >> > > > >> > However from reading the various posts, some of which are in the > bugzilla > > >> > entry, it appears that many distros may be, or have changed to this > > >> > configuration, and this will undoubtedly break several things, rxtx > > >> > included. > > >> > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > with the > > >> > no lock file option during configure, and that solved his problem. > > >> > > > >> > As this issue will probably take some time to get resolved across > all the > > >> > various Linux distros, it might be worth considering changing the > default > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > >> > versions of the lib in the binary archive. > > >> > > > >> > Thanks for your indulgence > > >> > > > >> > Andy > > >> > > > >> > _______________________________________________ > > >> > Rxtx mailing list > > >> > Rxtx at qbang.org > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > >> > > > >> > > >> > > >> > > >> -- > > >> Atte: > > >> Daniel Dario Morales Salas > > >> Ingeniero Civil en Computaci?n e Inform?tica > > >> Tel?fono: 02 684 3417 > > >> Celular: 09 643 1802 > > >> Santiago, Chile > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at qbang.org > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > -- > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > WWW: http://www.sharms.org/blog > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Thu Feb 4 05:31:46 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 12:31:46 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: <20100204123146.6cffeb67@workstation.site> Thank's for the confirmation. Something odd is going on somewhere in SUSE 11.2. I'll have to build up a local SUSE11.2 system to see if I can nail down exactly what is going on. Something is blocking the lockfiles in var/lock. The net is nice, but it's a bit difficult trying to work out what is going on what the machine in question is in Germany and I'm in the UK :-) Andy On Wed, 3 Feb 2010 22:26:38 -0300 Daniel Morales Salas wrote: > Hello > > I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva > 2010 this is what i get: > > drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ > > and i don't have ANY problem with lock files and RXTX in my java software. > All i had to do was add this rule to udev: > > # serial > KERNEL=="tty*", GROUP="uucp", MODE="0666" > > and that was all. Of course my user (metalklesk) is part of uucp group. > I did not make /var/lock writable to all users. > > Greetings ! > > 2010/2/3 Andy Eskelson > > > Thanks Steve, > > > > changing the serial ports back the uucp is not a big problem. I have a > > udev rule that can be easily modified already. However I cannot see any > > way of dealing with the var/lock problem apart from making it writable to > > all. Any thoughts? > > > > Andy > > > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > > wrote: > > > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > > and is a result of unified udev rules. You can work around this by > > > making udev change the group back to uucp until something more > > > happens. > > > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > > > Thanks, > > > > > > Steve > > > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > > Thanks Daniel, > > > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > > this for other programs for some time. > > > > . > > > > I don't think that this is the same problem. as far as I can understand > > > > things, the lock files are written in var/lock. Previously var/lock and > > > > dev/tty-whatever were the same group. Now with var/lock owned by and > > with > > > > a group of root:root anything other than root cannot create a lock > > > > file. Even minicom is broken by this change. > > > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > > Daniel Morales Salas wrote: > > > > > > > >> Hi > > > >> > > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > > the uucp > > > >> group did not work as it used to be in earlier versions of linux > > distros, > > > >> causing RXTX to not work as non root user. > > > >> > > > >> The problem appears because the existense of UDEV, now you MUST add a > > RULE > > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > > the > > > >> Serial Port. > > > >> > > > >> To solve the problem, without needing to recompile RXTX, you must add > > a rule > > > >> to grant permissions (0666) to the group for the device or port (tty*, > > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > > i > > > >> come back home i will give it to you (i am at work now). > > > >> > > > >> Greetings ! > > > >> > > > >> 2010/2/3 > > > >> > > > >> > Hello RXTX group, > > > >> > > > > >> > I have just joined this group, and this is my first posting. > > > >> > I wanted to pass on some information regarding rxtx, so apologies > > if > > > >> > this has been brought up before. I have searched back through the > > > >> > archives but nothing specific came up. > > > >> > > > > >> > I am not a Java programmer, and I only came across rxtx a few days > > ago. > > > >> > > > > >> > I use a piece of test equipment called a miniVNA > > > >> > http://www.miniradiosolutions.com/ > > > >> > > > > >> > This is a serial USB controlled instrument, and it has control > > software > > > >> > available for MS windows, and a very old and now non-working Linux > > > >> > application. > > > >> > > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > > control the > > > >> > miniVNA, obviously this application makes use of rxtx. > > > >> > > > > >> > The program worked fine on Windows, so I set about installing it > > onto > > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > > running > > > >> > fairly easily, sorting out the file locking by adding the uucp group > > to > > > >> > the users account as suggested (I used the 2.2pre binary files) I > > then > > > >> > passed the install instructions onto another miniVNA user, who also > > uses > > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > > >> > also having file lock problems, but the uucp fix did not work. > > Digging > > > >> > into his system I found that there have been some changes in SUSE > > 11.2. > > > >> > > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > > >> > > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > > >> > checked, so: > > > >> > > > > >> > SUSE 11.1, var/lock is root:uucp > > > >> > SUSE 11.2 var/lock is root:root > > > >> > > > > >> > A search on Google brought up several comments regarding this, and > > also > > > >> > a bugzilla entry. > > > >> > > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > >> > > > > >> > However from reading the various posts, some of which are in the > > bugzilla > > > >> > entry, it appears that many distros may be, or have changed to this > > > >> > configuration, and this will undoubtedly break several things, rxtx > > > >> > included. > > > >> > > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > > with the > > > >> > no lock file option during configure, and that solved his problem. > > > >> > > > > >> > As this issue will probably take some time to get resolved across > > all the > > > >> > various Linux distros, it might be worth considering changing the > > default > > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > > >> > versions of the lib in the binary archive. > > > >> > > > > >> > Thanks for your indulgence > > > >> > > > > >> > Andy > > > >> > > > > >> > _______________________________________________ > > > >> > Rxtx mailing list > > > >> > Rxtx at qbang.org > > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > > >> > > > > >> > > > >> > > > >> > > > >> -- > > > >> Atte: > > > >> Daniel Dario Morales Salas > > > >> Ingeniero Civil en Computaci?n e Inform?tica > > > >> Tel?fono: 02 684 3417 > > > >> Celular: 09 643 1802 > > > >> Santiago, Chile > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at qbang.org > > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > > > -- > > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > > > WWW: http://www.sharms.org/blog > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From Bob_Jacobsen at lbl.gov Thu Feb 4 09:26:49 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Thu, 4 Feb 2010 08:26:49 -0800 Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 Message-ID: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're using RXTX-2.2pre2, although it emits the known message about "Version mismatch". WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 After the usual messing around, we've got it working on 11 Windows versions, multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ have things working rarely say so, so I don't know whether anybody has gotten it to work on 10.4 or not. The problem encountered is this: dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib dyld: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib followed by the JVM crashing hard. I've got those dump files if that would help. Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If so, is there a patch I can get and build? Thanks Bob -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From tjarvi at qbang.org Thu Feb 4 14:22:21 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 4 Feb 2010 14:22:21 -0700 (MST) Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 In-Reply-To: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> References: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> Message-ID: On Thu, 4 Feb 2010, Bob Jacobsen wrote: > We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're > using RXTX-2.2pre2, although it emits the known message about "Version > mismatch". > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > > After the usual messing around, we've got it working on 11 Windows versions, > multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with > a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ > have things working rarely say so, so I don't know whether anybody has gotten > it to work on 10.4 or not. > > The problem encountered is this: > > dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > dyld: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > followed by the JVM crashing hard. I've got those dump files if that would > help. > > Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If > so, is there a patch I can get and build? > Hi Bob, I talked to a coworker about the problem you ran into. It appears that it is possible to target 'older' Mac systems through makefile configuration changes. "Configuring a Makefile-Based Project If you have a makefile-based project, you can also take advantage of SDK-based development, by adding the appropriate options to your compile and link commands. Using SDKs in makefile-based projects requires GCC 4.0 or later. To choose an SDK, you use the -isysroot option with the compiler and the -syslibroot option with the linker. Both options require that you specify the full path to the desired SDK directory. To set the Deployment OS version in a makefile, use a makefile variable of the form: ENVP= MACOSX_DEPLOYMENT_TARGET=10.4. To use this variable in your makefile, include it in front of your compile and link commands." http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html Or build on the oldest system you want to support. -- Trent Jarvi tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Thu Feb 4 14:56:19 2010 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Thu, 4 Feb 2010 14:56:19 -0700 Subject: [Rxtx] RXTX on 64 Bit Redhat In-Reply-To: References: <4ec9eab61001281448g3dd84910r867619948a4e0d7a@mail.gmail.com> Message-ID: Trent -- Finally fixed all my build related issues. I ran into another issue. On one of my machines my JDK is returning multiple folders for the "java.ext.dirs" (java.ext.dirs -> /opt/jdk1.6.0_17/jre/lib/ext:/usr/java/packages/lib/ext) system property. As a result my JVM wasn't able to detect the gnu.io.rxtx.properties. I am attaching a patch for RXTXCommDriver.java file to check for multiple locations. Also i have to assign permission 660 to all my dev ports to be located by RXTX. Pawan ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 5:12 PM To: Trent Jarvi Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Here is the error i get when i build the src from release-2-1-7 -bash-3.2$ make ( \ \ cd i686-pc-linux-gnu; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/ jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I/opt/jav a1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec - c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialImp.lo;\ if [ "Serial" = "Serial" ]; then \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I /opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_tim espec -c /home/jb_stg/rxtx/rxtx-devel/./src/fuserImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ else \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo; \ fi; \ ) gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/inclu de -I/opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need _timespec -c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -fPIC -DPIC -o /hom e/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/.libs/SerialImp.o /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:25:29: error: gnu_io_RXTXPort.h: No such file or directory In file included from /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:113: /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:91: error: expected specifier-qua lifier-list before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'jobject' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:408: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:409: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:410: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:411: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:415: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:416: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:417: error: expected '=', ',', '; ', 'asm' or '__attribute__' before 'is_interrupted' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:418: error: expected declaration specifiers or '...' before 'jint' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:424: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:441: error: expected ')' before ' *' token ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 4:57 PM To: Santosh Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Santosh -- Thank you. That fixed the issue. All -- What CVS branch or release should i use to get the latest RXTX src code. Pawan ________________________________ From: Santosh [mailto:santosh.ry at gmail.com] Sent: Thursday, January 28, 2010 3:49 PM To: Kharbanda, Pawan Cc: Trent Jarvi; rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat error "./configure: /bin/sh^M: bad interpreter: No such file or directory". I think you need to run dos2unix on script files before compiling. Thanks, Santosh On Thu, Jan 28, 2010 at 5:33 PM, Kharbanda, Pawan > wrote: Trent -- We are upgrading our exisiting OS and JDK on a project that rely heavily on RXTX api's. We are now using JDK1.6 32 bit (build 1.6.0_17-b04) and RedHat 5 on a 64 bit machine. Linux tocrhstg02.dot.state.co.us 2.6.18-164.6.1.el5 #1 SMP Tue Oct 27 11:30:06 EDT 2009 i686 i686 i386 GNU/Linux Red Hat Enterprise Linux Server release 5.4 (Tikanga) I tried to run version 2.1.7 r2 on it but not able to see any of my Digi ports I was able to access only /dev/ttyS0 (physical ports). Not sure if the problem is with the Digi driver or RXTX. I tried to open a Digi port with minicom and it worked fine. I also tried to get latest from CVS (rxtx-devel) and when I do "configure" I see this error "./configure: /bin/sh^M: bad interpreter: No such file or directory". Can someone please help me with this? Thanks for the help. Pawan _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch.txt URL: From juan.vicente.l.g at gmail.com Sat Feb 13 04:44:17 2010 From: juan.vicente.l.g at gmail.com (Juan Vicente Lopez Gutierrez) Date: Sat, 13 Feb 2010 12:44:17 +0100 Subject: [Rxtx] RXTX in macmini OSX 10.5 Message-ID: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> Hello. My name is Juanvi and I'm from Spain. I tried to launch a software created by me in the library CXR java to send information through the serial port and I can not make it work. In windows if I've done but not mac. I have a mac mini with OSX 10.5 and have read in the list of web mail that you CXR if you have managed to make it work on that operating system. I need you help me please. Do I make the mistake that shows me java: run: Stable Library =============================== Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 gnu.io.PortInUseException: Unknow Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:26) at TwoWatSerialComm.main(TwoWaySerialComm.java:106) Experimental: JNI_OnLoad called. GENERACION CORRECTA (total time: 0 seconds) I do not have permission to access the serial port, do not know. Os agradeceria much to sit down. A greeting and thanks. Pardon my English. Juanvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From juan.vicente.l.g at gmail.com Sat Feb 13 14:39:41 2010 From: juan.vicente.l.g at gmail.com (Juan Vicente Lopez Gutierrez) Date: Sat, 13 Feb 2010 22:39:41 +0100 Subject: [Rxtx] Fwd: RXTX in macmini OSX 10.5 In-Reply-To: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> References: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> Message-ID: <29405e5c1002131339m2059d169sdc8549ed9706a1af@mail.gmail.com> ---------- Forwarded message ---------- From: Juan Vicente Lopez Gutierrez Date: 2010/2/13 Subject: RXTX in macmini OSX 10.5 To: rxtx at qbang.org Hello. My name is Juanvi and I'm from Spain. I tried to launch a software created by me in the library CXR java to send information through the serial port and I can not make it work. In windows if I've done but not mac. I have a mac mini with OSX 10.5 and have read in the list of web mail that you CXR if you have managed to make it work on that operating system. I need you help me please. Do I make the mistake that shows me java: run: Stable Library =============================== Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 gnu.io.PortInUseException: Unknow Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:26) at TwoWatSerialComm.main(TwoWaySerialComm.java:106) Experimental: JNI_OnLoad called. GENERACION CORRECTA (total time: 0 seconds) I do not have permission to access the serial port, do not know. Os agradeceria much to sit down. A greeting and thanks. Pardon my English. Juanvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 01:02:21 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 13:32:21 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> My serial port driver(apparently) does not support receive timeout.I registered an event listener for DATA_AVAILABLE. However, the control never seems to come out of the 'while' loop.Shouldn't the InputStream.read return a '-1' immediately if no data is available (this seems to be the default operation)? This was tried on a x86 Linux desktop using rxtx-2.1-7 I've added the snippet for clarity: /******************************************************************************************************************************************************************************/ mySerialPort.enableReceiveThreshold(2000);//Trying to set a time limit for read calls System.out.println(mySerialPort.isReceiveTimeoutEnabled()); // I get FALSE, so its not supported on hardware. mySerialPort.addEventListener(this); mySerialPort.notifyOnDataAvailable(true);//register a event with //my SerialEvent listener implementation: public void serialEvent(SerialPortEvent arg0) { int newData=0; switch(arg0.getEventType()){ case SerialPortEvent.DATA_AVAILABLE: while (newData != -1) { try { newData = is.read();//This should eventually return a -1 if no data is available within a timeout.PROBLEM!! System.out.println("Got a byte from port:"+newData); if (newData == -1) { break; } } catch (IOException ex) { System.err.println(ex); return; } } break; } return; } /******************************************************************************************************************************************************************************/ Thanks and regards, Ravi From michael.erskine at ketech.com Wed Feb 3 02:26:50 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 09:26:50 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From michael.erskine at ketech.com Wed Feb 3 05:03:30 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 12:03:30 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > Michael Erskine > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > > Your event handler should handle the event and return immediately so that its > controlling thread can handle other events. I recommend a single read in the > following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) > reads all available bytes up to the size of the buffer returning the number of > bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } After posting this I considered the glaring possibility of the rawbuf read buffer being too small to receive all the available bytes and perhaps skipping data: after all, I'm guessing that is why we see so many posts asking for help with blocking implementations of read event handlers looping on "while(bytes are available)". I've spent this morning writing an extensive multi-threaded unit test suite that includes tests with a tiny buffer compared to the amount of data available and found that no data was being skipped. I now want to know why! The SerialPortEvent.DATA_AVAILABLE event must be being fired again if there is more data available on the input stream. If that is the case then it should be heavily documented with good examples in the wiki to avoid the types of developer anguish we see so regularly. BTW: I'm not at liberty to post the JUnit tests as they use my company's unit test suite framework. Regards, Michael Erskine. From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 06:18:04 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 18:48:04 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Hello Michael, I tried out your suggestion but the problem is that the read(rawbuf) blocks until the entire length of the rawbuf array has been read (blocking). I cannot decide on a reasonable size of the array because it varies from 2 bytes to as much as 50 byes (i'm communicating with a modem,each response is of a different length), which is why i wanted to use non blocking calls. But on a side note, read(byte[]) in turn calls the read() in a loop.In the native C function, the read is supposed to return a -1 upon timeout.But my driver does not support timeout.The default timeout value is zero and the linux select call upon zero time out causes an infinite wait.What am i missing...... Thanks and regards, Ravi Date: Wed, 3 Feb 2010 09:26:50 +0000 From: Michael Erskine To: "rxtx at qbang.org" Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: Content-Type: text/plain; charset="us-ascii" > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From m.kirkland at comcast.net Wed Feb 3 06:46:03 2010 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 3 Feb 2010 05:46:03 -0800 Subject: [Rxtx] One port blocking another port In-Reply-To: References: Message-ID: <68768633814F4D7D86761D34F0764FE0@bengal.net> It turns out this is caused by having the RTS/CTS flow control turned on and me not providing a true on the RTS pin. Somehow it seems the port timing out on a read allows the write to proceed. This is not an issue for my application but I wonder if the write should not proceed until the RTS pin is true even if a read times out. mk -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Monday, January 25, 2010 7:48 PM To: Mike Kirkland Cc: rxtx at qbang.org Subject: Re: [Rxtx] One port blocking another port On Mon, 25 Jan 2010, Mike Kirkland wrote: > > Hi All, > > ? > > I have a program that reads from one com port and writes to another com > port. It also does the same thing in reverse (reads from the second com port > and writes to the first one. It basically ties two com ports together. > > ? > > One port is very chatty and has a consent stream of data. The other port has > very little data. > > ? > > Both ports use a 5000 ms (5 second) time out. > > ? > > The issue I am having is that is appears that the first port?s write to the > second port is blocked while the second port is waiting for input. The first > port?s write proceeds only after the second port has timed out. > > ? > > I suppose I could have something twisted around in my code but I was > wondering if this is a know issue? > Hi Kirk, I've not seen a report like this. Perhaps some simple reproduction code will reveal a problem on your end or help us identify a problem in rxtx. I think there are several users doing multiport communication. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Wed Feb 3 07:03:58 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:03:58 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Message-ID: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> 2010/2/3 Ravishankar N > Hello Michael, > [..] > But on a side note, read(byte[]) in turn calls the read() in a loop.In the > native C function, the read is supposed to return a -1 upon timeout.But my > driver > does not support timeout.The default timeout value is zero and the linux > select call upon zero time out causes an infinite wait.What am i > missing...... > > When I have tested RXTX between platforms, I have observed "hangup" inside JNI driver when no data in Linux, is normal thing. Solution was setting the timeout for RXTX when no data from JNI driver. Something like that: commPort.enableReceiveTimeout(10); And it works perfect.... The only difference is that I am NOT using events - I am using continous read in separate thread and if data is available, is parsed and transferred to application using exception. Regards Mariusz > Thanks and regards, > Ravi > > Date: Wed, 3 Feb 2010 09:26:50 +0000 > From: Michael Erskine > To: "rxtx at qbang.org" > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > Message-ID: > > > Content-Type: text/plain; charset="us-ascii" > > > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of > > Ravishankar N > > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > > > My serial port driver(apparently) does not support receive timeout.I > > registered an event listener for DATA_AVAILABLE. However, the control > never > > seems to come out of the 'while' loop.Shouldn't the > > InputStream.read return a '-1' immediately if no data is available (this > seems > > to be the default operation)? > > Your event handler should handle the event and return immediately so that > its controlling thread can handle other events. I recommend a single read in > the following manner: rawbuf is a byte[] of "reasonable" size and the > read(byte[]) reads all available bytes up to the size of the buffer > returning the number of bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } > > This style of reading has worked for me with RXTX on Linux and Windows XP > for a good few years now in railway industry communications systems. Any > timeouts (largely unnecessary in my applications) can be handled elsewhere, > usually at a higher layer. > > Regards, > Michael Erskine. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Feb 3 07:22:55 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 3 Feb 2010 09:22:55 -0500 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: I'm guessing that this is driver specific. I recently had to support a select()/poll() infrastructure for a linux serial DD, its certainly non trivial to support async IO, so I suspect the problem in this case has to do with missing poll infrastructure in the device driver. This also has to coupled with special open flags for the device (which is within the rxtx code) The key routines within a 2.6 kernel linux device driver are shown below (if you have access to it for your particular device) are indicated below (here is a snippet from my device driver c code that supports polling/select). User space code to test this shown below also, note that the device needs to be opened with the O_NONBLOCK option to support the select/poll api // device driver code ..... /* * File operations supported by this driver. */ static struct file_operations iop_fops = { .owner = THIS_MODULE, .check_flags= iop_check_flags, .ioctl = iop_ioctl, .open = iop_open, .poll = iop_poll, // SUPPORT FOR SELECT/POLL infrastructure .read = iop_read, .release = iop_release, .write = iop_write, }; /** * Select/poll/epoll infrastructure. * * @param file * @param wait * * @return */ static unsigned int iop_poll(struct file *filp, poll_table *wait) { struct iop_device *devp = (struct iop_device *)filp->private_data; // the poll_table wait arg is an opaque pointer poll_wait(filp, &devp->readq, wait); // return from poll indicating whether we have read/write data unsigned int mask = 0; if (kfifo_len(devp->rx_fifo)) { mask |= (POLLIN | POLLRDNORM); } // @JC We don't do select on write yet // if (kfifo_len(devp->tx_fifo)) { // mask |= (POLLOUT | POLLWRNORM); // } // Only print out while debugging // if (mask != 0) { // printk (KERN_INFO "%s: [%04x]\n", __FUNCTION__, mask); // } return mask; } /** * device driver blocking and non blocking read function. This * function reads the requested number of bytes from the read * kfifo blocking as required. * * @param filp * @param buf * @param count * @param f_pos * * @return */ static ssize_t iop_read(struct file *filp, char __user *buf, size_t count, loff_t * ppos) { // access appropriate device struct struct iop_device *devp = (struct iop_device *) filp->private_data; ssize_t retval; // support non blocking mode (default) by checking if the kfifo is empty first if ((kfifo_len(devp->rx_fifo)==0) && (filp->f_flags & O_NONBLOCK)) { return -EAGAIN; } // wait for rx_fifo to receive data via receive interrupts retval = wait_event_interruptible(devp->readq, kfifo_len(devp->rx_fifo) != 0); // check for some error condition if (retval) { printk (KERN_ERR "%s: wait_event_interruptible returned[%d]\n", __FUNCTION__, retval); return retval; } // copy max requested bytes from rx_fifo to device buffer // this may still leave bytes in the kfifo for a subsequent read // if we are reading in a loop retval = kfifo_get(devp->rx_fifo, devp->rxbuf, count); // printk (KERN_INFO "%s: [%d] byte(s)\n", __FUNCTION__, retval); if (copy_to_user(buf, devp->rxbuf, retval)) { printk (KERN_ERR "%s: problem copying rx_fifo data to user buffer\n", __FUNCTION__); return -EFAULT; } return retval; } // a selection of my user space code reading via select()/poll()..... // user space open code iop_fd = ::open( deviceName.data(), O_RDWR | O_NONBLOCK); while ((bytes_to_expect - bytes_read) > 0) { // must reinitialize these between select calls fd_set readfds; FD_ZERO( &readfds ); FD_SET( iop_fd, &readfds ); // 1s sec read polling timeout struct timeval timeout; timeout.tv_sec = 1; timeout.tv_usec = 0; int rc = select( FD_SETSIZE, &readfds, NULL, NULL, &timeout ); // read from file when descriptor // indicates data available without blocking if ((rc > 0) && FD_ISSET(iop_fd, &readfds)) { // read into the appropriate offset within the rx_buf int temp = read(iop_fd, rx_buf + bytes_read, bytes_to_expect - bytes_read); if (!temp) { printf("EOF detected with %d bytes expected\n", bytes_to_expect - bytes_read); } else { bytes_read += temp; } } else if (rc < 0){ printf("%s: select on [%s], bytes_read[%d], errno=%d\n", __FUNCTION__, thread_args->device, bytes_read, errno); } else { printf("%s: select on [%s], bytes_read[%d], timeout\n", __FUNCTION__, thread_args->device, bytes_read); } } On Wed, Feb 3, 2010 at 9:03 AM, Mariusz Dec wrote: > > > 2010/2/3 Ravishankar N > >> Hello Michael, >> [..] >> >> But on a side note, read(byte[]) in turn calls the read() in a loop.In the >> native C function, the read is supposed to return a -1 upon timeout.But my >> driver >> does not support timeout.The default timeout value is zero and the linux >> select call upon zero time out causes an infinite wait.What am i >> missing...... >> >> > When I have tested RXTX between platforms, I have observed "hangup" inside > JNI driver when no data in Linux, is normal thing. > > Solution was setting the timeout for RXTX when no data from JNI driver. > > Something like that: > > commPort.enableReceiveTimeout(10); > > And it works perfect.... > > The only difference is that I am NOT using events - I am using continous > read in separate thread and if data is available, is parsed and transferred > to application using exception. > > Regards > Mariusz > > > >> Thanks and regards, >> Ravi >> >> Date: Wed, 3 Feb 2010 09:26:50 +0000 >> From: Michael Erskine >> To: "rxtx at qbang.org" >> Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? >> Message-ID: >> >> >> Content-Type: text/plain; charset="us-ascii" >> >> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >> Of >> > Ravishankar N >> > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? >> > >> > My serial port driver(apparently) does not support receive timeout.I >> > registered an event listener for DATA_AVAILABLE. However, the control >> never >> > seems to come out of the 'while' loop.Shouldn't the >> > InputStream.read return a '-1' immediately if no data is available (this >> seems >> > to be the default operation)? >> >> Your event handler should handle the event and return immediately so that >> its controlling thread can handle other events. I recommend a single read in >> the following manner: rawbuf is a byte[] of "reasonable" size and the >> read(byte[]) reads all available bytes up to the size of the buffer >> returning the number of bytes actually read... >> >> case SerialPortEvent.DATA_AVAILABLE: >> try { >> int i = is.read(rawbuf); >> if (i == -1) { >> << process EOF condition - should never happen >> >> return; >> } >> << process bytes (rawbuf, i); >> >> return; >> } catch (IOException e) { >> << promptly deal with exception >> >> return; >> } >> >> This style of reading has worked for me with RXTX on Linux and Windows XP >> for a good few years now in railway industry communications systems. Any >> timeouts (largely unnecessary in my applications) can be handled elsewhere, >> usually at a higher layer. >> >> Regards, >> Michael Erskine. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Feb 3 07:33:27 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:33:27 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: <73a89f361002030633j682610afia48dc7accd8e049b@mail.gmail.com> 2010/2/3 John Coffey > I'm guessing that this is driver specific. I recently had to support a > select()/poll() infrastructure for a linux serial DD, its certainly non > trivial to support async IO, so I suspect the problem in this case has to do > with missing poll infrastructure in the device driver. This also has to > coupled with special open flags for the device (which is within the rxtx > code) > > Yes, you are right, it may be driver specific, but in my case I haven't changed blocking JNI driver. I have added ONLY one call to RXTX method mentioned in my previous post and blocking (as seen as from Java app) gone out... Maybe this is not elegant, but works without problem in my app. I am using only FTDI chips and their drivers from couple of years and maybe this is the kind of the way to have no many problems with serial as well? Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From andyrxtx at g0poy.co.uk Wed Feb 3 11:09:04 2010 From: andyrxtx at g0poy.co.uk (andyrxtx at g0poy.co.uk) Date: Wed, 3 Feb 2010 18:09:04 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes Message-ID: <20100203180904.164f24dd@workstation.site> ?Hello RXTX group, I have just joined this group, and this is my first posting. I wanted to pass on some information regarding rxtx, so apologies if this has been brought up before. I have searched back through the archives but nothing specific came up. I am not a Java programmer, and I only came across rxtx a few days ago. I use a piece of test equipment called a miniVNA http://www.miniradiosolutions.com/ This is a serial USB controlled instrument, and it has control software available for MS windows, and a very old and now non-working Linux application. A few days ago Dietmar, DL2SBA released a Java application to control the miniVNA, obviously this application makes use of rxtx. The program worked fine on Windows, so I set about installing it onto Linux. I use SUSE11.1 After a few false starts, I got the system running fairly easily, sorting out the file locking by adding the uucp group to the users account as suggested (I used the 2.2pre binary files) I then passed the install instructions onto another miniVNA user, who also uses SUSE, but he ran into problems. To cut a long story short, he was also having file lock problems, but the uucp fix did not work. Digging into his system I found that there have been some changes in SUSE 11.2. tty ports are now assigned to the dialout group rather than uucp. A hint in the rxtx INSTALL file, suggested that var/lock needs to be checked, so: SUSE 11.1, var/lock is root:uucp SUSE 11.2 var/lock is root:root A search on Google brought up several comments regarding this, and also a bugzilla entry. https://bugzilla.novell.com/show_bug.cgi?id=552095 However from reading the various posts, some of which are in the bugzilla entry, it appears that many distros may be, or have changed to this configuration, and this will undoubtedly break several things, rxtx included. I solved my fellow SUSE users problem by compiling the rxtx libs with the no lock file option during configure, and that solved his problem. As this issue will probably take some time to get resolved across all the various Linux distros, it might be worth considering changing the default on the Linux build of rxtx not to use lockfiles, or provide the two versions of the lib in the binary archive. Thanks for your indulgence Andy From damorales at gmail.com Wed Feb 3 11:33:23 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 15:33:23 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203180904.164f24dd@workstation.site> References: <20100203180904.164f24dd@workstation.site> Message-ID: Hi I had the same problem in Mandriva 2010 and yes, adding the user to the uucp group did not work as it used to be in earlier versions of linux distros, causing RXTX to not work as non root user. The problem appears because the existense of UDEV, now you MUST add a RULE so the group (uucp or whatever) have access (Read, Write, Execute) to the Serial Port. To solve the problem, without needing to recompile RXTX, you must add a rule to grant permissions (0666) to the group for the device or port (tty*, ttyUSB*, etc). I do not remember now what is the line i added but when i come back home i will give it to you (i am at work now). Greetings ! 2010/2/3 > Hello RXTX group, > > I have just joined this group, and this is my first posting. > I wanted to pass on some information regarding rxtx, so apologies if > this has been brought up before. I have searched back through the > archives but nothing specific came up. > > I am not a Java programmer, and I only came across rxtx a few days ago. > > I use a piece of test equipment called a miniVNA > http://www.miniradiosolutions.com/ > > This is a serial USB controlled instrument, and it has control software > available for MS windows, and a very old and now non-working Linux > application. > > A few days ago Dietmar, DL2SBA released a Java application to control the > miniVNA, obviously this application makes use of rxtx. > > The program worked fine on Windows, so I set about installing it onto > Linux. I use SUSE11.1 After a few false starts, I got the system running > fairly easily, sorting out the file locking by adding the uucp group to > the users account as suggested (I used the 2.2pre binary files) I then > passed the install instructions onto another miniVNA user, who also uses > SUSE, but he ran into problems. To cut a long story short, he was > also having file lock problems, but the uucp fix did not work. Digging > into his system I found that there have been some changes in SUSE 11.2. > > tty ports are now assigned to the dialout group rather than uucp. > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > checked, so: > > SUSE 11.1, var/lock is root:uucp > SUSE 11.2 var/lock is root:root > > A search on Google brought up several comments regarding this, and also > a bugzilla entry. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > However from reading the various posts, some of which are in the bugzilla > entry, it appears that many distros may be, or have changed to this > configuration, and this will undoubtedly break several things, rxtx > included. > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > no lock file option during configure, and that solved his problem. > > As this issue will probably take some time to get resolved across all the > various Linux distros, it might be worth considering changing the default > on the Linux build of rxtx not to use lockfiles, or provide the two > versions of the lib in the binary archive. > > Thanks for your indulgence > > Andy > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Wed Feb 3 12:07:02 2010 From: andy at g0poy.com (Andy Eskelson) Date: Wed, 3 Feb 2010 19:07:02 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> Message-ID: <20100203190702.1b0e7015@workstation.site> Thanks Daniel, I am aware of the permissions problem, I have had a udev rules to solve this for other programs for some time. . I don't think that this is the same problem. as far as I can understand things, the lock files are written in var/lock. Previously var/lock and dev/tty-whatever were the same group. Now with var/lock owned by and with a group of root:root anything other than root cannot create a lock file. Even minicom is broken by this change. This change is going to have quite a few knock-on effects I think. Andy On Wed, 3 Feb 2010 15:33:23 -0300 Daniel Morales Salas wrote: > Hi > > I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > group did not work as it used to be in earlier versions of linux distros, > causing RXTX to not work as non root user. > > The problem appears because the existense of UDEV, now you MUST add a RULE > so the group (uucp or whatever) have access (Read, Write, Execute) to the > Serial Port. > > To solve the problem, without needing to recompile RXTX, you must add a rule > to grant permissions (0666) to the group for the device or port (tty*, > ttyUSB*, etc). I do not remember now what is the line i added but when i > come back home i will give it to you (i am at work now). > > Greetings ! > > 2010/2/3 > > > Hello RXTX group, > > > > I have just joined this group, and this is my first posting. > > I wanted to pass on some information regarding rxtx, so apologies if > > this has been brought up before. I have searched back through the > > archives but nothing specific came up. > > > > I am not a Java programmer, and I only came across rxtx a few days ago. > > > > I use a piece of test equipment called a miniVNA > > http://www.miniradiosolutions.com/ > > > > This is a serial USB controlled instrument, and it has control software > > available for MS windows, and a very old and now non-working Linux > > application. > > > > A few days ago Dietmar, DL2SBA released a Java application to control the > > miniVNA, obviously this application makes use of rxtx. > > > > The program worked fine on Windows, so I set about installing it onto > > Linux. I use SUSE11.1 After a few false starts, I got the system running > > fairly easily, sorting out the file locking by adding the uucp group to > > the users account as suggested (I used the 2.2pre binary files) I then > > passed the install instructions onto another miniVNA user, who also uses > > SUSE, but he ran into problems. To cut a long story short, he was > > also having file lock problems, but the uucp fix did not work. Digging > > into his system I found that there have been some changes in SUSE 11.2. > > > > tty ports are now assigned to the dialout group rather than uucp. > > > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > checked, so: > > > > SUSE 11.1, var/lock is root:uucp > > SUSE 11.2 var/lock is root:root > > > > A search on Google brought up several comments regarding this, and also > > a bugzilla entry. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > However from reading the various posts, some of which are in the bugzilla > > entry, it appears that many distros may be, or have changed to this > > configuration, and this will undoubtedly break several things, rxtx > > included. > > > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > > no lock file option during configure, and that solved his problem. > > > > As this issue will probably take some time to get resolved across all the > > various Linux distros, it might be worth considering changing the default > > on the Linux build of rxtx not to use lockfiles, or provide the two > > versions of the lib in the binary archive. > > > > Thanks for your indulgence > > > > Andy > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From thisdyingdream at gmail.com Wed Feb 3 12:32:35 2010 From: thisdyingdream at gmail.com (Steven Harms) Date: Wed, 3 Feb 2010 14:32:35 -0500 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203190702.1b0e7015@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: This is currently a bug in OpenSUSE that affects more than just rxtx, and is a result of unified udev rules. You can work around this by making udev change the group back to uucp until something more happens. https://bugzilla.novell.com/show_bug.cgi?id=552095 Thanks, Steve On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > Thanks Daniel, > > I am aware of the permissions problem, I have had a udev rules to solve > this for other programs for some time. > . > I don't think that this is the same problem. as far as I can understand > things, the lock files are written in var/lock. Previously var/lock and > dev/tty-whatever were the same group. Now with var/lock owned by and with > a group of root:root anything other than root cannot create a lock > file. Even minicom is broken by this change. > > This change is going to have quite a few knock-on effects I think. > > > Andy > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > Daniel Morales Salas wrote: > >> Hi >> >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp >> group did not work as it used to be in earlier versions of linux distros, >> causing RXTX to not work as non root user. >> >> The problem appears because the existense of UDEV, now you MUST add a RULE >> so the group (uucp or whatever) have access (Read, Write, Execute) to the >> Serial Port. >> >> To solve the problem, without needing to recompile RXTX, you must add a rule >> to grant permissions (0666) to the group for the device or port (tty*, >> ttyUSB*, etc). I do not remember now what is the line i added but when i >> come back home i will give it to you (i am at work now). >> >> Greetings ! >> >> 2010/2/3 >> >> > Hello RXTX group, >> > >> > I have just joined this group, and this is my first posting. >> > I wanted to pass on ?some information regarding rxtx, so apologies if >> > this has been brought up before. I have searched back through the >> > archives but nothing specific came up. >> > >> > I am not a Java programmer, and I only came across rxtx a few days ago. >> > >> > I use a piece of test equipment called a miniVNA >> > http://www.miniradiosolutions.com/ >> > >> > This is a serial USB controlled instrument, and it has control software >> > available for MS windows, and a very old and now non-working Linux >> > application. >> > >> > A few days ago Dietmar, DL2SBA released a Java application to control the >> > miniVNA, obviously this application makes use of rxtx. >> > >> > The program worked fine on Windows, so I set about installing it onto >> > Linux. I use SUSE11.1 After a few false starts, I got the system running >> > fairly easily, sorting out the file locking by adding the uucp group to >> > the users account as suggested (I used the 2.2pre binary files) I then >> > passed the install instructions onto another miniVNA user, who also uses >> > SUSE, but he ran into problems. To cut a long story short, he was >> > also having file lock problems, but the uucp fix did not work. Digging >> > into his system I found that there have been some changes in SUSE 11.2. >> > >> > tty ports are now assigned to the dialout group rather than uucp. >> > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be >> > checked, so: >> > >> > SUSE 11.1, var/lock is root:uucp >> > SUSE 11.2 var/lock is root:root >> > >> > A search on Google brought up several comments regarding this, and also >> > a ?bugzilla entry. >> > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 >> > >> > However from reading the various posts, some of which are in the bugzilla >> > entry, it appears that many distros may be, or have changed to this >> > configuration, and this will undoubtedly break several things, rxtx >> > included. >> > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the >> > no lock file option during configure, and that solved his problem. >> > >> > As this issue will probably take some time to get resolved across all the >> > various Linux distros, it might be worth considering changing the default >> > on the Linux build of rxtx not to use lockfiles, or provide the two >> > versions of the lib in the binary archive. >> > >> > Thanks for your indulgence >> > >> > Andy >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> >> >> >> -- >> Atte: >> Daniel Dario Morales Salas >> Ingeniero Civil en Computaci?n e Inform?tica >> Tel?fono: 02 684 3417 >> Celular: 09 643 1802 >> Santiago, Chile > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 WWW: http://www.sharms.org/blog From andy at g0poy.com Wed Feb 3 17:58:29 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 00:58:29 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: <20100204005829.7dc944e1@workstation.site> Thanks Steve, changing the serial ports back the uucp is not a big problem. I have a udev rule that can be easily modified already. However I cannot see any way of dealing with the var/lock problem apart from making it writable to all. Any thoughts? Andy On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms wrote: > This is currently a bug in OpenSUSE that affects more than just rxtx, > and is a result of unified udev rules. You can work around this by > making udev change the group back to uucp until something more > happens. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > Thanks, > > Steve > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > Thanks Daniel, > > > > I am aware of the permissions problem, I have had a udev rules to solve > > this for other programs for some time. > > . > > I don't think that this is the same problem. as far as I can understand > > things, the lock files are written in var/lock. Previously var/lock and > > dev/tty-whatever were the same group. Now with var/lock owned by and with > > a group of root:root anything other than root cannot create a lock > > file. Even minicom is broken by this change. > > > > This change is going to have quite a few knock-on effects I think. > > > > > > Andy > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > Daniel Morales Salas wrote: > > > >> Hi > >> > >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > >> group did not work as it used to be in earlier versions of linux distros, > >> causing RXTX to not work as non root user. > >> > >> The problem appears because the existense of UDEV, now you MUST add a RULE > >> so the group (uucp or whatever) have access (Read, Write, Execute) to the > >> Serial Port. > >> > >> To solve the problem, without needing to recompile RXTX, you must add a rule > >> to grant permissions (0666) to the group for the device or port (tty*, > >> ttyUSB*, etc). I do not remember now what is the line i added but when i > >> come back home i will give it to you (i am at work now). > >> > >> Greetings ! > >> > >> 2010/2/3 > >> > >> > Hello RXTX group, > >> > > >> > I have just joined this group, and this is my first posting. > >> > I wanted to pass on ?some information regarding rxtx, so apologies if > >> > this has been brought up before. I have searched back through the > >> > archives but nothing specific came up. > >> > > >> > I am not a Java programmer, and I only came across rxtx a few days ago. > >> > > >> > I use a piece of test equipment called a miniVNA > >> > http://www.miniradiosolutions.com/ > >> > > >> > This is a serial USB controlled instrument, and it has control software > >> > available for MS windows, and a very old and now non-working Linux > >> > application. > >> > > >> > A few days ago Dietmar, DL2SBA released a Java application to control the > >> > miniVNA, obviously this application makes use of rxtx. > >> > > >> > The program worked fine on Windows, so I set about installing it onto > >> > Linux. I use SUSE11.1 After a few false starts, I got the system running > >> > fairly easily, sorting out the file locking by adding the uucp group to > >> > the users account as suggested (I used the 2.2pre binary files) I then > >> > passed the install instructions onto another miniVNA user, who also uses > >> > SUSE, but he ran into problems. To cut a long story short, he was > >> > also having file lock problems, but the uucp fix did not work. Digging > >> > into his system I found that there have been some changes in SUSE 11.2. > >> > > >> > tty ports are now assigned to the dialout group rather than uucp. > >> > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > >> > checked, so: > >> > > >> > SUSE 11.1, var/lock is root:uucp > >> > SUSE 11.2 var/lock is root:root > >> > > >> > A search on Google brought up several comments regarding this, and also > >> > a ?bugzilla entry. > >> > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > >> > > >> > However from reading the various posts, some of which are in the bugzilla > >> > entry, it appears that many distros may be, or have changed to this > >> > configuration, and this will undoubtedly break several things, rxtx > >> > included. > >> > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the > >> > no lock file option during configure, and that solved his problem. > >> > > >> > As this issue will probably take some time to get resolved across all the > >> > various Linux distros, it might be worth considering changing the default > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > >> > versions of the lib in the binary archive. > >> > > >> > Thanks for your indulgence > >> > > >> > Andy > >> > > >> > _______________________________________________ > >> > Rxtx mailing list > >> > Rxtx at qbang.org > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > >> > >> > >> > >> -- > >> Atte: > >> Daniel Dario Morales Salas > >> Ingeniero Civil en Computaci?n e Inform?tica > >> Tel?fono: 02 684 3417 > >> Celular: 09 643 1802 > >> Santiago, Chile > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > WWW: http://www.sharms.org/blog From damorales at gmail.com Wed Feb 3 18:26:38 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 22:26:38 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100204005829.7dc944e1@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: Hello I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva 2010 this is what i get: drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ and i don't have ANY problem with lock files and RXTX in my java software. All i had to do was add this rule to udev: # serial KERNEL=="tty*", GROUP="uucp", MODE="0666" and that was all. Of course my user (metalklesk) is part of uucp group. I did not make /var/lock writable to all users. Greetings ! 2010/2/3 Andy Eskelson > Thanks Steve, > > changing the serial ports back the uucp is not a big problem. I have a > udev rule that can be easily modified already. However I cannot see any > way of dealing with the var/lock problem apart from making it writable to > all. Any thoughts? > > Andy > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > wrote: > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > and is a result of unified udev rules. You can work around this by > > making udev change the group back to uucp until something more > > happens. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > Thanks, > > > > Steve > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > Thanks Daniel, > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > this for other programs for some time. > > > . > > > I don't think that this is the same problem. as far as I can understand > > > things, the lock files are written in var/lock. Previously var/lock and > > > dev/tty-whatever were the same group. Now with var/lock owned by and > with > > > a group of root:root anything other than root cannot create a lock > > > file. Even minicom is broken by this change. > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > Daniel Morales Salas wrote: > > > > > >> Hi > > >> > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > the uucp > > >> group did not work as it used to be in earlier versions of linux > distros, > > >> causing RXTX to not work as non root user. > > >> > > >> The problem appears because the existense of UDEV, now you MUST add a > RULE > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > the > > >> Serial Port. > > >> > > >> To solve the problem, without needing to recompile RXTX, you must add > a rule > > >> to grant permissions (0666) to the group for the device or port (tty*, > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > i > > >> come back home i will give it to you (i am at work now). > > >> > > >> Greetings ! > > >> > > >> 2010/2/3 > > >> > > >> > Hello RXTX group, > > >> > > > >> > I have just joined this group, and this is my first posting. > > >> > I wanted to pass on some information regarding rxtx, so apologies > if > > >> > this has been brought up before. I have searched back through the > > >> > archives but nothing specific came up. > > >> > > > >> > I am not a Java programmer, and I only came across rxtx a few days > ago. > > >> > > > >> > I use a piece of test equipment called a miniVNA > > >> > http://www.miniradiosolutions.com/ > > >> > > > >> > This is a serial USB controlled instrument, and it has control > software > > >> > available for MS windows, and a very old and now non-working Linux > > >> > application. > > >> > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > control the > > >> > miniVNA, obviously this application makes use of rxtx. > > >> > > > >> > The program worked fine on Windows, so I set about installing it > onto > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > running > > >> > fairly easily, sorting out the file locking by adding the uucp group > to > > >> > the users account as suggested (I used the 2.2pre binary files) I > then > > >> > passed the install instructions onto another miniVNA user, who also > uses > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > >> > also having file lock problems, but the uucp fix did not work. > Digging > > >> > into his system I found that there have been some changes in SUSE > 11.2. > > >> > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > >> > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > >> > checked, so: > > >> > > > >> > SUSE 11.1, var/lock is root:uucp > > >> > SUSE 11.2 var/lock is root:root > > >> > > > >> > A search on Google brought up several comments regarding this, and > also > > >> > a bugzilla entry. > > >> > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > >> > > > >> > However from reading the various posts, some of which are in the > bugzilla > > >> > entry, it appears that many distros may be, or have changed to this > > >> > configuration, and this will undoubtedly break several things, rxtx > > >> > included. > > >> > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > with the > > >> > no lock file option during configure, and that solved his problem. > > >> > > > >> > As this issue will probably take some time to get resolved across > all the > > >> > various Linux distros, it might be worth considering changing the > default > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > >> > versions of the lib in the binary archive. > > >> > > > >> > Thanks for your indulgence > > >> > > > >> > Andy > > >> > > > >> > _______________________________________________ > > >> > Rxtx mailing list > > >> > Rxtx at qbang.org > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > >> > > > >> > > >> > > >> > > >> -- > > >> Atte: > > >> Daniel Dario Morales Salas > > >> Ingeniero Civil en Computaci?n e Inform?tica > > >> Tel?fono: 02 684 3417 > > >> Celular: 09 643 1802 > > >> Santiago, Chile > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at qbang.org > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > -- > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > WWW: http://www.sharms.org/blog > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Thu Feb 4 05:31:46 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 12:31:46 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: <20100204123146.6cffeb67@workstation.site> Thank's for the confirmation. Something odd is going on somewhere in SUSE 11.2. I'll have to build up a local SUSE11.2 system to see if I can nail down exactly what is going on. Something is blocking the lockfiles in var/lock. The net is nice, but it's a bit difficult trying to work out what is going on what the machine in question is in Germany and I'm in the UK :-) Andy On Wed, 3 Feb 2010 22:26:38 -0300 Daniel Morales Salas wrote: > Hello > > I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva > 2010 this is what i get: > > drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ > > and i don't have ANY problem with lock files and RXTX in my java software. > All i had to do was add this rule to udev: > > # serial > KERNEL=="tty*", GROUP="uucp", MODE="0666" > > and that was all. Of course my user (metalklesk) is part of uucp group. > I did not make /var/lock writable to all users. > > Greetings ! > > 2010/2/3 Andy Eskelson > > > Thanks Steve, > > > > changing the serial ports back the uucp is not a big problem. I have a > > udev rule that can be easily modified already. However I cannot see any > > way of dealing with the var/lock problem apart from making it writable to > > all. Any thoughts? > > > > Andy > > > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > > wrote: > > > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > > and is a result of unified udev rules. You can work around this by > > > making udev change the group back to uucp until something more > > > happens. > > > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > > > Thanks, > > > > > > Steve > > > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > > Thanks Daniel, > > > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > > this for other programs for some time. > > > > . > > > > I don't think that this is the same problem. as far as I can understand > > > > things, the lock files are written in var/lock. Previously var/lock and > > > > dev/tty-whatever were the same group. Now with var/lock owned by and > > with > > > > a group of root:root anything other than root cannot create a lock > > > > file. Even minicom is broken by this change. > > > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > > Daniel Morales Salas wrote: > > > > > > > >> Hi > > > >> > > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > > the uucp > > > >> group did not work as it used to be in earlier versions of linux > > distros, > > > >> causing RXTX to not work as non root user. > > > >> > > > >> The problem appears because the existense of UDEV, now you MUST add a > > RULE > > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > > the > > > >> Serial Port. > > > >> > > > >> To solve the problem, without needing to recompile RXTX, you must add > > a rule > > > >> to grant permissions (0666) to the group for the device or port (tty*, > > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > > i > > > >> come back home i will give it to you (i am at work now). > > > >> > > > >> Greetings ! > > > >> > > > >> 2010/2/3 > > > >> > > > >> > Hello RXTX group, > > > >> > > > > >> > I have just joined this group, and this is my first posting. > > > >> > I wanted to pass on some information regarding rxtx, so apologies > > if > > > >> > this has been brought up before. I have searched back through the > > > >> > archives but nothing specific came up. > > > >> > > > > >> > I am not a Java programmer, and I only came across rxtx a few days > > ago. > > > >> > > > > >> > I use a piece of test equipment called a miniVNA > > > >> > http://www.miniradiosolutions.com/ > > > >> > > > > >> > This is a serial USB controlled instrument, and it has control > > software > > > >> > available for MS windows, and a very old and now non-working Linux > > > >> > application. > > > >> > > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > > control the > > > >> > miniVNA, obviously this application makes use of rxtx. > > > >> > > > > >> > The program worked fine on Windows, so I set about installing it > > onto > > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > > running > > > >> > fairly easily, sorting out the file locking by adding the uucp group > > to > > > >> > the users account as suggested (I used the 2.2pre binary files) I > > then > > > >> > passed the install instructions onto another miniVNA user, who also > > uses > > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > > >> > also having file lock problems, but the uucp fix did not work. > > Digging > > > >> > into his system I found that there have been some changes in SUSE > > 11.2. > > > >> > > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > > >> > > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > > >> > checked, so: > > > >> > > > > >> > SUSE 11.1, var/lock is root:uucp > > > >> > SUSE 11.2 var/lock is root:root > > > >> > > > > >> > A search on Google brought up several comments regarding this, and > > also > > > >> > a bugzilla entry. > > > >> > > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > >> > > > > >> > However from reading the various posts, some of which are in the > > bugzilla > > > >> > entry, it appears that many distros may be, or have changed to this > > > >> > configuration, and this will undoubtedly break several things, rxtx > > > >> > included. > > > >> > > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > > with the > > > >> > no lock file option during configure, and that solved his problem. > > > >> > > > > >> > As this issue will probably take some time to get resolved across > > all the > > > >> > various Linux distros, it might be worth considering changing the > > default > > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > > >> > versions of the lib in the binary archive. > > > >> > > > > >> > Thanks for your indulgence > > > >> > > > > >> > Andy > > > >> > > > > >> > _______________________________________________ > > > >> > Rxtx mailing list > > > >> > Rxtx at qbang.org > > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > > >> > > > > >> > > > >> > > > >> > > > >> -- > > > >> Atte: > > > >> Daniel Dario Morales Salas > > > >> Ingeniero Civil en Computaci?n e Inform?tica > > > >> Tel?fono: 02 684 3417 > > > >> Celular: 09 643 1802 > > > >> Santiago, Chile > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at qbang.org > > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > > > -- > > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > > > WWW: http://www.sharms.org/blog > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From Bob_Jacobsen at lbl.gov Thu Feb 4 09:26:49 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Thu, 4 Feb 2010 08:26:49 -0800 Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 Message-ID: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're using RXTX-2.2pre2, although it emits the known message about "Version mismatch". WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 After the usual messing around, we've got it working on 11 Windows versions, multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ have things working rarely say so, so I don't know whether anybody has gotten it to work on 10.4 or not. The problem encountered is this: dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib dyld: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib followed by the JVM crashing hard. I've got those dump files if that would help. Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If so, is there a patch I can get and build? Thanks Bob -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From tjarvi at qbang.org Thu Feb 4 14:22:21 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 4 Feb 2010 14:22:21 -0700 (MST) Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 In-Reply-To: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> References: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> Message-ID: On Thu, 4 Feb 2010, Bob Jacobsen wrote: > We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're > using RXTX-2.2pre2, although it emits the known message about "Version > mismatch". > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > > After the usual messing around, we've got it working on 11 Windows versions, > multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with > a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ > have things working rarely say so, so I don't know whether anybody has gotten > it to work on 10.4 or not. > > The problem encountered is this: > > dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > dyld: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > followed by the JVM crashing hard. I've got those dump files if that would > help. > > Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If > so, is there a patch I can get and build? > Hi Bob, I talked to a coworker about the problem you ran into. It appears that it is possible to target 'older' Mac systems through makefile configuration changes. "Configuring a Makefile-Based Project If you have a makefile-based project, you can also take advantage of SDK-based development, by adding the appropriate options to your compile and link commands. Using SDKs in makefile-based projects requires GCC 4.0 or later. To choose an SDK, you use the -isysroot option with the compiler and the -syslibroot option with the linker. Both options require that you specify the full path to the desired SDK directory. To set the Deployment OS version in a makefile, use a makefile variable of the form: ENVP= MACOSX_DEPLOYMENT_TARGET=10.4. To use this variable in your makefile, include it in front of your compile and link commands." http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html Or build on the oldest system you want to support. -- Trent Jarvi tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Thu Feb 4 14:56:19 2010 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Thu, 4 Feb 2010 14:56:19 -0700 Subject: [Rxtx] RXTX on 64 Bit Redhat In-Reply-To: References: <4ec9eab61001281448g3dd84910r867619948a4e0d7a@mail.gmail.com> Message-ID: Trent -- Finally fixed all my build related issues. I ran into another issue. On one of my machines my JDK is returning multiple folders for the "java.ext.dirs" (java.ext.dirs -> /opt/jdk1.6.0_17/jre/lib/ext:/usr/java/packages/lib/ext) system property. As a result my JVM wasn't able to detect the gnu.io.rxtx.properties. I am attaching a patch for RXTXCommDriver.java file to check for multiple locations. Also i have to assign permission 660 to all my dev ports to be located by RXTX. Pawan ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 5:12 PM To: Trent Jarvi Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Here is the error i get when i build the src from release-2-1-7 -bash-3.2$ make ( \ \ cd i686-pc-linux-gnu; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/ jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I/opt/jav a1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec - c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialImp.lo;\ if [ "Serial" = "Serial" ]; then \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I /opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_tim espec -c /home/jb_stg/rxtx/rxtx-devel/./src/fuserImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ else \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo; \ fi; \ ) gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/inclu de -I/opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need _timespec -c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -fPIC -DPIC -o /hom e/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/.libs/SerialImp.o /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:25:29: error: gnu_io_RXTXPort.h: No such file or directory In file included from /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:113: /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:91: error: expected specifier-qua lifier-list before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'jobject' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:408: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:409: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:410: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:411: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:415: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:416: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:417: error: expected '=', ',', '; ', 'asm' or '__attribute__' before 'is_interrupted' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:418: error: expected declaration specifiers or '...' before 'jint' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:424: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:441: error: expected ')' before ' *' token ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 4:57 PM To: Santosh Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Santosh -- Thank you. That fixed the issue. All -- What CVS branch or release should i use to get the latest RXTX src code. Pawan ________________________________ From: Santosh [mailto:santosh.ry at gmail.com] Sent: Thursday, January 28, 2010 3:49 PM To: Kharbanda, Pawan Cc: Trent Jarvi; rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat error "./configure: /bin/sh^M: bad interpreter: No such file or directory". I think you need to run dos2unix on script files before compiling. Thanks, Santosh On Thu, Jan 28, 2010 at 5:33 PM, Kharbanda, Pawan > wrote: Trent -- We are upgrading our exisiting OS and JDK on a project that rely heavily on RXTX api's. We are now using JDK1.6 32 bit (build 1.6.0_17-b04) and RedHat 5 on a 64 bit machine. Linux tocrhstg02.dot.state.co.us 2.6.18-164.6.1.el5 #1 SMP Tue Oct 27 11:30:06 EDT 2009 i686 i686 i386 GNU/Linux Red Hat Enterprise Linux Server release 5.4 (Tikanga) I tried to run version 2.1.7 r2 on it but not able to see any of my Digi ports I was able to access only /dev/ttyS0 (physical ports). Not sure if the problem is with the Digi driver or RXTX. I tried to open a Digi port with minicom and it worked fine. I also tried to get latest from CVS (rxtx-devel) and when I do "configure" I see this error "./configure: /bin/sh^M: bad interpreter: No such file or directory". Can someone please help me with this? Thanks for the help. Pawan _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch.txt URL: From juan.vicente.l.g at gmail.com Sat Feb 13 04:44:17 2010 From: juan.vicente.l.g at gmail.com (Juan Vicente Lopez Gutierrez) Date: Sat, 13 Feb 2010 12:44:17 +0100 Subject: [Rxtx] RXTX in macmini OSX 10.5 Message-ID: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> Hello. My name is Juanvi and I'm from Spain. I tried to launch a software created by me in the library CXR java to send information through the serial port and I can not make it work. In windows if I've done but not mac. I have a mac mini with OSX 10.5 and have read in the list of web mail that you CXR if you have managed to make it work on that operating system. I need you help me please. Do I make the mistake that shows me java: run: Stable Library =============================== Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 gnu.io.PortInUseException: Unknow Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:26) at TwoWatSerialComm.main(TwoWaySerialComm.java:106) Experimental: JNI_OnLoad called. GENERACION CORRECTA (total time: 0 seconds) I do not have permission to access the serial port, do not know. Os agradeceria much to sit down. A greeting and thanks. Pardon my English. Juanvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From juan.vicente.l.g at gmail.com Sat Feb 13 14:39:41 2010 From: juan.vicente.l.g at gmail.com (Juan Vicente Lopez Gutierrez) Date: Sat, 13 Feb 2010 22:39:41 +0100 Subject: [Rxtx] Fwd: RXTX in macmini OSX 10.5 In-Reply-To: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> References: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> Message-ID: <29405e5c1002131339m2059d169sdc8549ed9706a1af@mail.gmail.com> ---------- Forwarded message ---------- From: Juan Vicente Lopez Gutierrez Date: 2010/2/13 Subject: RXTX in macmini OSX 10.5 To: rxtx at qbang.org Hello. My name is Juanvi and I'm from Spain. I tried to launch a software created by me in the library CXR java to send information through the serial port and I can not make it work. In windows if I've done but not mac. I have a mac mini with OSX 10.5 and have read in the list of web mail that you CXR if you have managed to make it work on that operating system. I need you help me please. Do I make the mistake that shows me java: run: Stable Library =============================== Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 gnu.io.PortInUseException: Unknow Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:26) at TwoWatSerialComm.main(TwoWaySerialComm.java:106) Experimental: JNI_OnLoad called. GENERACION CORRECTA (total time: 0 seconds) I do not have permission to access the serial port, do not know. Os agradeceria much to sit down. A greeting and thanks. Pardon my English. Juanvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 01:02:21 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 13:32:21 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> My serial port driver(apparently) does not support receive timeout.I registered an event listener for DATA_AVAILABLE. However, the control never seems to come out of the 'while' loop.Shouldn't the InputStream.read return a '-1' immediately if no data is available (this seems to be the default operation)? This was tried on a x86 Linux desktop using rxtx-2.1-7 I've added the snippet for clarity: /******************************************************************************************************************************************************************************/ mySerialPort.enableReceiveThreshold(2000);//Trying to set a time limit for read calls System.out.println(mySerialPort.isReceiveTimeoutEnabled()); // I get FALSE, so its not supported on hardware. mySerialPort.addEventListener(this); mySerialPort.notifyOnDataAvailable(true);//register a event with //my SerialEvent listener implementation: public void serialEvent(SerialPortEvent arg0) { int newData=0; switch(arg0.getEventType()){ case SerialPortEvent.DATA_AVAILABLE: while (newData != -1) { try { newData = is.read();//This should eventually return a -1 if no data is available within a timeout.PROBLEM!! System.out.println("Got a byte from port:"+newData); if (newData == -1) { break; } } catch (IOException ex) { System.err.println(ex); return; } } break; } return; } /******************************************************************************************************************************************************************************/ Thanks and regards, Ravi From michael.erskine at ketech.com Wed Feb 3 02:26:50 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 09:26:50 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From michael.erskine at ketech.com Wed Feb 3 05:03:30 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 12:03:30 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > Michael Erskine > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > > Your event handler should handle the event and return immediately so that its > controlling thread can handle other events. I recommend a single read in the > following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) > reads all available bytes up to the size of the buffer returning the number of > bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } After posting this I considered the glaring possibility of the rawbuf read buffer being too small to receive all the available bytes and perhaps skipping data: after all, I'm guessing that is why we see so many posts asking for help with blocking implementations of read event handlers looping on "while(bytes are available)". I've spent this morning writing an extensive multi-threaded unit test suite that includes tests with a tiny buffer compared to the amount of data available and found that no data was being skipped. I now want to know why! The SerialPortEvent.DATA_AVAILABLE event must be being fired again if there is more data available on the input stream. If that is the case then it should be heavily documented with good examples in the wiki to avoid the types of developer anguish we see so regularly. BTW: I'm not at liberty to post the JUnit tests as they use my company's unit test suite framework. Regards, Michael Erskine. From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 06:18:04 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 18:48:04 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Hello Michael, I tried out your suggestion but the problem is that the read(rawbuf) blocks until the entire length of the rawbuf array has been read (blocking). I cannot decide on a reasonable size of the array because it varies from 2 bytes to as much as 50 byes (i'm communicating with a modem,each response is of a different length), which is why i wanted to use non blocking calls. But on a side note, read(byte[]) in turn calls the read() in a loop.In the native C function, the read is supposed to return a -1 upon timeout.But my driver does not support timeout.The default timeout value is zero and the linux select call upon zero time out causes an infinite wait.What am i missing...... Thanks and regards, Ravi Date: Wed, 3 Feb 2010 09:26:50 +0000 From: Michael Erskine To: "rxtx at qbang.org" Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: Content-Type: text/plain; charset="us-ascii" > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From m.kirkland at comcast.net Wed Feb 3 06:46:03 2010 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 3 Feb 2010 05:46:03 -0800 Subject: [Rxtx] One port blocking another port In-Reply-To: References: Message-ID: <68768633814F4D7D86761D34F0764FE0@bengal.net> It turns out this is caused by having the RTS/CTS flow control turned on and me not providing a true on the RTS pin. Somehow it seems the port timing out on a read allows the write to proceed. This is not an issue for my application but I wonder if the write should not proceed until the RTS pin is true even if a read times out. mk -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Monday, January 25, 2010 7:48 PM To: Mike Kirkland Cc: rxtx at qbang.org Subject: Re: [Rxtx] One port blocking another port On Mon, 25 Jan 2010, Mike Kirkland wrote: > > Hi All, > > ? > > I have a program that reads from one com port and writes to another com > port. It also does the same thing in reverse (reads from the second com port > and writes to the first one. It basically ties two com ports together. > > ? > > One port is very chatty and has a consent stream of data. The other port has > very little data. > > ? > > Both ports use a 5000 ms (5 second) time out. > > ? > > The issue I am having is that is appears that the first port?s write to the > second port is blocked while the second port is waiting for input. The first > port?s write proceeds only after the second port has timed out. > > ? > > I suppose I could have something twisted around in my code but I was > wondering if this is a know issue? > Hi Kirk, I've not seen a report like this. Perhaps some simple reproduction code will reveal a problem on your end or help us identify a problem in rxtx. I think there are several users doing multiport communication. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Wed Feb 3 07:03:58 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:03:58 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Message-ID: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> 2010/2/3 Ravishankar N > Hello Michael, > [..] > But on a side note, read(byte[]) in turn calls the read() in a loop.In the > native C function, the read is supposed to return a -1 upon timeout.But my > driver > does not support timeout.The default timeout value is zero and the linux > select call upon zero time out causes an infinite wait.What am i > missing...... > > When I have tested RXTX between platforms, I have observed "hangup" inside JNI driver when no data in Linux, is normal thing. Solution was setting the timeout for RXTX when no data from JNI driver. Something like that: commPort.enableReceiveTimeout(10); And it works perfect.... The only difference is that I am NOT using events - I am using continous read in separate thread and if data is available, is parsed and transferred to application using exception. Regards Mariusz > Thanks and regards, > Ravi > > Date: Wed, 3 Feb 2010 09:26:50 +0000 > From: Michael Erskine > To: "rxtx at qbang.org" > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > Message-ID: > > > Content-Type: text/plain; charset="us-ascii" > > > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of > > Ravishankar N > > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > > > My serial port driver(apparently) does not support receive timeout.I > > registered an event listener for DATA_AVAILABLE. However, the control > never > > seems to come out of the 'while' loop.Shouldn't the > > InputStream.read return a '-1' immediately if no data is available (this > seems > > to be the default operation)? > > Your event handler should handle the event and return immediately so that > its controlling thread can handle other events. I recommend a single read in > the following manner: rawbuf is a byte[] of "reasonable" size and the > read(byte[]) reads all available bytes up to the size of the buffer > returning the number of bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } > > This style of reading has worked for me with RXTX on Linux and Windows XP > for a good few years now in railway industry communications systems. Any > timeouts (largely unnecessary in my applications) can be handled elsewhere, > usually at a higher layer. > > Regards, > Michael Erskine. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Feb 3 07:22:55 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 3 Feb 2010 09:22:55 -0500 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: I'm guessing that this is driver specific. I recently had to support a select()/poll() infrastructure for a linux serial DD, its certainly non trivial to support async IO, so I suspect the problem in this case has to do with missing poll infrastructure in the device driver. This also has to coupled with special open flags for the device (which is within the rxtx code) The key routines within a 2.6 kernel linux device driver are shown below (if you have access to it for your particular device) are indicated below (here is a snippet from my device driver c code that supports polling/select). User space code to test this shown below also, note that the device needs to be opened with the O_NONBLOCK option to support the select/poll api // device driver code ..... /* * File operations supported by this driver. */ static struct file_operations iop_fops = { .owner = THIS_MODULE, .check_flags= iop_check_flags, .ioctl = iop_ioctl, .open = iop_open, .poll = iop_poll, // SUPPORT FOR SELECT/POLL infrastructure .read = iop_read, .release = iop_release, .write = iop_write, }; /** * Select/poll/epoll infrastructure. * * @param file * @param wait * * @return */ static unsigned int iop_poll(struct file *filp, poll_table *wait) { struct iop_device *devp = (struct iop_device *)filp->private_data; // the poll_table wait arg is an opaque pointer poll_wait(filp, &devp->readq, wait); // return from poll indicating whether we have read/write data unsigned int mask = 0; if (kfifo_len(devp->rx_fifo)) { mask |= (POLLIN | POLLRDNORM); } // @JC We don't do select on write yet // if (kfifo_len(devp->tx_fifo)) { // mask |= (POLLOUT | POLLWRNORM); // } // Only print out while debugging // if (mask != 0) { // printk (KERN_INFO "%s: [%04x]\n", __FUNCTION__, mask); // } return mask; } /** * device driver blocking and non blocking read function. This * function reads the requested number of bytes from the read * kfifo blocking as required. * * @param filp * @param buf * @param count * @param f_pos * * @return */ static ssize_t iop_read(struct file *filp, char __user *buf, size_t count, loff_t * ppos) { // access appropriate device struct struct iop_device *devp = (struct iop_device *) filp->private_data; ssize_t retval; // support non blocking mode (default) by checking if the kfifo is empty first if ((kfifo_len(devp->rx_fifo)==0) && (filp->f_flags & O_NONBLOCK)) { return -EAGAIN; } // wait for rx_fifo to receive data via receive interrupts retval = wait_event_interruptible(devp->readq, kfifo_len(devp->rx_fifo) != 0); // check for some error condition if (retval) { printk (KERN_ERR "%s: wait_event_interruptible returned[%d]\n", __FUNCTION__, retval); return retval; } // copy max requested bytes from rx_fifo to device buffer // this may still leave bytes in the kfifo for a subsequent read // if we are reading in a loop retval = kfifo_get(devp->rx_fifo, devp->rxbuf, count); // printk (KERN_INFO "%s: [%d] byte(s)\n", __FUNCTION__, retval); if (copy_to_user(buf, devp->rxbuf, retval)) { printk (KERN_ERR "%s: problem copying rx_fifo data to user buffer\n", __FUNCTION__); return -EFAULT; } return retval; } // a selection of my user space code reading via select()/poll()..... // user space open code iop_fd = ::open( deviceName.data(), O_RDWR | O_NONBLOCK); while ((bytes_to_expect - bytes_read) > 0) { // must reinitialize these between select calls fd_set readfds; FD_ZERO( &readfds ); FD_SET( iop_fd, &readfds ); // 1s sec read polling timeout struct timeval timeout; timeout.tv_sec = 1; timeout.tv_usec = 0; int rc = select( FD_SETSIZE, &readfds, NULL, NULL, &timeout ); // read from file when descriptor // indicates data available without blocking if ((rc > 0) && FD_ISSET(iop_fd, &readfds)) { // read into the appropriate offset within the rx_buf int temp = read(iop_fd, rx_buf + bytes_read, bytes_to_expect - bytes_read); if (!temp) { printf("EOF detected with %d bytes expected\n", bytes_to_expect - bytes_read); } else { bytes_read += temp; } } else if (rc < 0){ printf("%s: select on [%s], bytes_read[%d], errno=%d\n", __FUNCTION__, thread_args->device, bytes_read, errno); } else { printf("%s: select on [%s], bytes_read[%d], timeout\n", __FUNCTION__, thread_args->device, bytes_read); } } On Wed, Feb 3, 2010 at 9:03 AM, Mariusz Dec wrote: > > > 2010/2/3 Ravishankar N > >> Hello Michael, >> [..] >> >> But on a side note, read(byte[]) in turn calls the read() in a loop.In the >> native C function, the read is supposed to return a -1 upon timeout.But my >> driver >> does not support timeout.The default timeout value is zero and the linux >> select call upon zero time out causes an infinite wait.What am i >> missing...... >> >> > When I have tested RXTX between platforms, I have observed "hangup" inside > JNI driver when no data in Linux, is normal thing. > > Solution was setting the timeout for RXTX when no data from JNI driver. > > Something like that: > > commPort.enableReceiveTimeout(10); > > And it works perfect.... > > The only difference is that I am NOT using events - I am using continous > read in separate thread and if data is available, is parsed and transferred > to application using exception. > > Regards > Mariusz > > > >> Thanks and regards, >> Ravi >> >> Date: Wed, 3 Feb 2010 09:26:50 +0000 >> From: Michael Erskine >> To: "rxtx at qbang.org" >> Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? >> Message-ID: >> >> >> Content-Type: text/plain; charset="us-ascii" >> >> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >> Of >> > Ravishankar N >> > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? >> > >> > My serial port driver(apparently) does not support receive timeout.I >> > registered an event listener for DATA_AVAILABLE. However, the control >> never >> > seems to come out of the 'while' loop.Shouldn't the >> > InputStream.read return a '-1' immediately if no data is available (this >> seems >> > to be the default operation)? >> >> Your event handler should handle the event and return immediately so that >> its controlling thread can handle other events. I recommend a single read in >> the following manner: rawbuf is a byte[] of "reasonable" size and the >> read(byte[]) reads all available bytes up to the size of the buffer >> returning the number of bytes actually read... >> >> case SerialPortEvent.DATA_AVAILABLE: >> try { >> int i = is.read(rawbuf); >> if (i == -1) { >> << process EOF condition - should never happen >> >> return; >> } >> << process bytes (rawbuf, i); >> >> return; >> } catch (IOException e) { >> << promptly deal with exception >> >> return; >> } >> >> This style of reading has worked for me with RXTX on Linux and Windows XP >> for a good few years now in railway industry communications systems. Any >> timeouts (largely unnecessary in my applications) can be handled elsewhere, >> usually at a higher layer. >> >> Regards, >> Michael Erskine. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Feb 3 07:33:27 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:33:27 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: <73a89f361002030633j682610afia48dc7accd8e049b@mail.gmail.com> 2010/2/3 John Coffey > I'm guessing that this is driver specific. I recently had to support a > select()/poll() infrastructure for a linux serial DD, its certainly non > trivial to support async IO, so I suspect the problem in this case has to do > with missing poll infrastructure in the device driver. This also has to > coupled with special open flags for the device (which is within the rxtx > code) > > Yes, you are right, it may be driver specific, but in my case I haven't changed blocking JNI driver. I have added ONLY one call to RXTX method mentioned in my previous post and blocking (as seen as from Java app) gone out... Maybe this is not elegant, but works without problem in my app. I am using only FTDI chips and their drivers from couple of years and maybe this is the kind of the way to have no many problems with serial as well? Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From andyrxtx at g0poy.co.uk Wed Feb 3 11:09:04 2010 From: andyrxtx at g0poy.co.uk (andyrxtx at g0poy.co.uk) Date: Wed, 3 Feb 2010 18:09:04 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes Message-ID: <20100203180904.164f24dd@workstation.site> ?Hello RXTX group, I have just joined this group, and this is my first posting. I wanted to pass on some information regarding rxtx, so apologies if this has been brought up before. I have searched back through the archives but nothing specific came up. I am not a Java programmer, and I only came across rxtx a few days ago. I use a piece of test equipment called a miniVNA http://www.miniradiosolutions.com/ This is a serial USB controlled instrument, and it has control software available for MS windows, and a very old and now non-working Linux application. A few days ago Dietmar, DL2SBA released a Java application to control the miniVNA, obviously this application makes use of rxtx. The program worked fine on Windows, so I set about installing it onto Linux. I use SUSE11.1 After a few false starts, I got the system running fairly easily, sorting out the file locking by adding the uucp group to the users account as suggested (I used the 2.2pre binary files) I then passed the install instructions onto another miniVNA user, who also uses SUSE, but he ran into problems. To cut a long story short, he was also having file lock problems, but the uucp fix did not work. Digging into his system I found that there have been some changes in SUSE 11.2. tty ports are now assigned to the dialout group rather than uucp. A hint in the rxtx INSTALL file, suggested that var/lock needs to be checked, so: SUSE 11.1, var/lock is root:uucp SUSE 11.2 var/lock is root:root A search on Google brought up several comments regarding this, and also a bugzilla entry. https://bugzilla.novell.com/show_bug.cgi?id=552095 However from reading the various posts, some of which are in the bugzilla entry, it appears that many distros may be, or have changed to this configuration, and this will undoubtedly break several things, rxtx included. I solved my fellow SUSE users problem by compiling the rxtx libs with the no lock file option during configure, and that solved his problem. As this issue will probably take some time to get resolved across all the various Linux distros, it might be worth considering changing the default on the Linux build of rxtx not to use lockfiles, or provide the two versions of the lib in the binary archive. Thanks for your indulgence Andy From damorales at gmail.com Wed Feb 3 11:33:23 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 15:33:23 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203180904.164f24dd@workstation.site> References: <20100203180904.164f24dd@workstation.site> Message-ID: Hi I had the same problem in Mandriva 2010 and yes, adding the user to the uucp group did not work as it used to be in earlier versions of linux distros, causing RXTX to not work as non root user. The problem appears because the existense of UDEV, now you MUST add a RULE so the group (uucp or whatever) have access (Read, Write, Execute) to the Serial Port. To solve the problem, without needing to recompile RXTX, you must add a rule to grant permissions (0666) to the group for the device or port (tty*, ttyUSB*, etc). I do not remember now what is the line i added but when i come back home i will give it to you (i am at work now). Greetings ! 2010/2/3 > Hello RXTX group, > > I have just joined this group, and this is my first posting. > I wanted to pass on some information regarding rxtx, so apologies if > this has been brought up before. I have searched back through the > archives but nothing specific came up. > > I am not a Java programmer, and I only came across rxtx a few days ago. > > I use a piece of test equipment called a miniVNA > http://www.miniradiosolutions.com/ > > This is a serial USB controlled instrument, and it has control software > available for MS windows, and a very old and now non-working Linux > application. > > A few days ago Dietmar, DL2SBA released a Java application to control the > miniVNA, obviously this application makes use of rxtx. > > The program worked fine on Windows, so I set about installing it onto > Linux. I use SUSE11.1 After a few false starts, I got the system running > fairly easily, sorting out the file locking by adding the uucp group to > the users account as suggested (I used the 2.2pre binary files) I then > passed the install instructions onto another miniVNA user, who also uses > SUSE, but he ran into problems. To cut a long story short, he was > also having file lock problems, but the uucp fix did not work. Digging > into his system I found that there have been some changes in SUSE 11.2. > > tty ports are now assigned to the dialout group rather than uucp. > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > checked, so: > > SUSE 11.1, var/lock is root:uucp > SUSE 11.2 var/lock is root:root > > A search on Google brought up several comments regarding this, and also > a bugzilla entry. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > However from reading the various posts, some of which are in the bugzilla > entry, it appears that many distros may be, or have changed to this > configuration, and this will undoubtedly break several things, rxtx > included. > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > no lock file option during configure, and that solved his problem. > > As this issue will probably take some time to get resolved across all the > various Linux distros, it might be worth considering changing the default > on the Linux build of rxtx not to use lockfiles, or provide the two > versions of the lib in the binary archive. > > Thanks for your indulgence > > Andy > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Wed Feb 3 12:07:02 2010 From: andy at g0poy.com (Andy Eskelson) Date: Wed, 3 Feb 2010 19:07:02 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> Message-ID: <20100203190702.1b0e7015@workstation.site> Thanks Daniel, I am aware of the permissions problem, I have had a udev rules to solve this for other programs for some time. . I don't think that this is the same problem. as far as I can understand things, the lock files are written in var/lock. Previously var/lock and dev/tty-whatever were the same group. Now with var/lock owned by and with a group of root:root anything other than root cannot create a lock file. Even minicom is broken by this change. This change is going to have quite a few knock-on effects I think. Andy On Wed, 3 Feb 2010 15:33:23 -0300 Daniel Morales Salas wrote: > Hi > > I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > group did not work as it used to be in earlier versions of linux distros, > causing RXTX to not work as non root user. > > The problem appears because the existense of UDEV, now you MUST add a RULE > so the group (uucp or whatever) have access (Read, Write, Execute) to the > Serial Port. > > To solve the problem, without needing to recompile RXTX, you must add a rule > to grant permissions (0666) to the group for the device or port (tty*, > ttyUSB*, etc). I do not remember now what is the line i added but when i > come back home i will give it to you (i am at work now). > > Greetings ! > > 2010/2/3 > > > Hello RXTX group, > > > > I have just joined this group, and this is my first posting. > > I wanted to pass on some information regarding rxtx, so apologies if > > this has been brought up before. I have searched back through the > > archives but nothing specific came up. > > > > I am not a Java programmer, and I only came across rxtx a few days ago. > > > > I use a piece of test equipment called a miniVNA > > http://www.miniradiosolutions.com/ > > > > This is a serial USB controlled instrument, and it has control software > > available for MS windows, and a very old and now non-working Linux > > application. > > > > A few days ago Dietmar, DL2SBA released a Java application to control the > > miniVNA, obviously this application makes use of rxtx. > > > > The program worked fine on Windows, so I set about installing it onto > > Linux. I use SUSE11.1 After a few false starts, I got the system running > > fairly easily, sorting out the file locking by adding the uucp group to > > the users account as suggested (I used the 2.2pre binary files) I then > > passed the install instructions onto another miniVNA user, who also uses > > SUSE, but he ran into problems. To cut a long story short, he was > > also having file lock problems, but the uucp fix did not work. Digging > > into his system I found that there have been some changes in SUSE 11.2. > > > > tty ports are now assigned to the dialout group rather than uucp. > > > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > checked, so: > > > > SUSE 11.1, var/lock is root:uucp > > SUSE 11.2 var/lock is root:root > > > > A search on Google brought up several comments regarding this, and also > > a bugzilla entry. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > However from reading the various posts, some of which are in the bugzilla > > entry, it appears that many distros may be, or have changed to this > > configuration, and this will undoubtedly break several things, rxtx > > included. > > > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > > no lock file option during configure, and that solved his problem. > > > > As this issue will probably take some time to get resolved across all the > > various Linux distros, it might be worth considering changing the default > > on the Linux build of rxtx not to use lockfiles, or provide the two > > versions of the lib in the binary archive. > > > > Thanks for your indulgence > > > > Andy > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From thisdyingdream at gmail.com Wed Feb 3 12:32:35 2010 From: thisdyingdream at gmail.com (Steven Harms) Date: Wed, 3 Feb 2010 14:32:35 -0500 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203190702.1b0e7015@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: This is currently a bug in OpenSUSE that affects more than just rxtx, and is a result of unified udev rules. You can work around this by making udev change the group back to uucp until something more happens. https://bugzilla.novell.com/show_bug.cgi?id=552095 Thanks, Steve On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > Thanks Daniel, > > I am aware of the permissions problem, I have had a udev rules to solve > this for other programs for some time. > . > I don't think that this is the same problem. as far as I can understand > things, the lock files are written in var/lock. Previously var/lock and > dev/tty-whatever were the same group. Now with var/lock owned by and with > a group of root:root anything other than root cannot create a lock > file. Even minicom is broken by this change. > > This change is going to have quite a few knock-on effects I think. > > > Andy > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > Daniel Morales Salas wrote: > >> Hi >> >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp >> group did not work as it used to be in earlier versions of linux distros, >> causing RXTX to not work as non root user. >> >> The problem appears because the existense of UDEV, now you MUST add a RULE >> so the group (uucp or whatever) have access (Read, Write, Execute) to the >> Serial Port. >> >> To solve the problem, without needing to recompile RXTX, you must add a rule >> to grant permissions (0666) to the group for the device or port (tty*, >> ttyUSB*, etc). I do not remember now what is the line i added but when i >> come back home i will give it to you (i am at work now). >> >> Greetings ! >> >> 2010/2/3 >> >> > Hello RXTX group, >> > >> > I have just joined this group, and this is my first posting. >> > I wanted to pass on ?some information regarding rxtx, so apologies if >> > this has been brought up before. I have searched back through the >> > archives but nothing specific came up. >> > >> > I am not a Java programmer, and I only came across rxtx a few days ago. >> > >> > I use a piece of test equipment called a miniVNA >> > http://www.miniradiosolutions.com/ >> > >> > This is a serial USB controlled instrument, and it has control software >> > available for MS windows, and a very old and now non-working Linux >> > application. >> > >> > A few days ago Dietmar, DL2SBA released a Java application to control the >> > miniVNA, obviously this application makes use of rxtx. >> > >> > The program worked fine on Windows, so I set about installing it onto >> > Linux. I use SUSE11.1 After a few false starts, I got the system running >> > fairly easily, sorting out the file locking by adding the uucp group to >> > the users account as suggested (I used the 2.2pre binary files) I then >> > passed the install instructions onto another miniVNA user, who also uses >> > SUSE, but he ran into problems. To cut a long story short, he was >> > also having file lock problems, but the uucp fix did not work. Digging >> > into his system I found that there have been some changes in SUSE 11.2. >> > >> > tty ports are now assigned to the dialout group rather than uucp. >> > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be >> > checked, so: >> > >> > SUSE 11.1, var/lock is root:uucp >> > SUSE 11.2 var/lock is root:root >> > >> > A search on Google brought up several comments regarding this, and also >> > a ?bugzilla entry. >> > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 >> > >> > However from reading the various posts, some of which are in the bugzilla >> > entry, it appears that many distros may be, or have changed to this >> > configuration, and this will undoubtedly break several things, rxtx >> > included. >> > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the >> > no lock file option during configure, and that solved his problem. >> > >> > As this issue will probably take some time to get resolved across all the >> > various Linux distros, it might be worth considering changing the default >> > on the Linux build of rxtx not to use lockfiles, or provide the two >> > versions of the lib in the binary archive. >> > >> > Thanks for your indulgence >> > >> > Andy >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> >> >> >> -- >> Atte: >> Daniel Dario Morales Salas >> Ingeniero Civil en Computaci?n e Inform?tica >> Tel?fono: 02 684 3417 >> Celular: 09 643 1802 >> Santiago, Chile > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 WWW: http://www.sharms.org/blog From andy at g0poy.com Wed Feb 3 17:58:29 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 00:58:29 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: <20100204005829.7dc944e1@workstation.site> Thanks Steve, changing the serial ports back the uucp is not a big problem. I have a udev rule that can be easily modified already. However I cannot see any way of dealing with the var/lock problem apart from making it writable to all. Any thoughts? Andy On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms wrote: > This is currently a bug in OpenSUSE that affects more than just rxtx, > and is a result of unified udev rules. You can work around this by > making udev change the group back to uucp until something more > happens. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > Thanks, > > Steve > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > Thanks Daniel, > > > > I am aware of the permissions problem, I have had a udev rules to solve > > this for other programs for some time. > > . > > I don't think that this is the same problem. as far as I can understand > > things, the lock files are written in var/lock. Previously var/lock and > > dev/tty-whatever were the same group. Now with var/lock owned by and with > > a group of root:root anything other than root cannot create a lock > > file. Even minicom is broken by this change. > > > > This change is going to have quite a few knock-on effects I think. > > > > > > Andy > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > Daniel Morales Salas wrote: > > > >> Hi > >> > >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > >> group did not work as it used to be in earlier versions of linux distros, > >> causing RXTX to not work as non root user. > >> > >> The problem appears because the existense of UDEV, now you MUST add a RULE > >> so the group (uucp or whatever) have access (Read, Write, Execute) to the > >> Serial Port. > >> > >> To solve the problem, without needing to recompile RXTX, you must add a rule > >> to grant permissions (0666) to the group for the device or port (tty*, > >> ttyUSB*, etc). I do not remember now what is the line i added but when i > >> come back home i will give it to you (i am at work now). > >> > >> Greetings ! > >> > >> 2010/2/3 > >> > >> > Hello RXTX group, > >> > > >> > I have just joined this group, and this is my first posting. > >> > I wanted to pass on ?some information regarding rxtx, so apologies if > >> > this has been brought up before. I have searched back through the > >> > archives but nothing specific came up. > >> > > >> > I am not a Java programmer, and I only came across rxtx a few days ago. > >> > > >> > I use a piece of test equipment called a miniVNA > >> > http://www.miniradiosolutions.com/ > >> > > >> > This is a serial USB controlled instrument, and it has control software > >> > available for MS windows, and a very old and now non-working Linux > >> > application. > >> > > >> > A few days ago Dietmar, DL2SBA released a Java application to control the > >> > miniVNA, obviously this application makes use of rxtx. > >> > > >> > The program worked fine on Windows, so I set about installing it onto > >> > Linux. I use SUSE11.1 After a few false starts, I got the system running > >> > fairly easily, sorting out the file locking by adding the uucp group to > >> > the users account as suggested (I used the 2.2pre binary files) I then > >> > passed the install instructions onto another miniVNA user, who also uses > >> > SUSE, but he ran into problems. To cut a long story short, he was > >> > also having file lock problems, but the uucp fix did not work. Digging > >> > into his system I found that there have been some changes in SUSE 11.2. > >> > > >> > tty ports are now assigned to the dialout group rather than uucp. > >> > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > >> > checked, so: > >> > > >> > SUSE 11.1, var/lock is root:uucp > >> > SUSE 11.2 var/lock is root:root > >> > > >> > A search on Google brought up several comments regarding this, and also > >> > a ?bugzilla entry. > >> > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > >> > > >> > However from reading the various posts, some of which are in the bugzilla > >> > entry, it appears that many distros may be, or have changed to this > >> > configuration, and this will undoubtedly break several things, rxtx > >> > included. > >> > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the > >> > no lock file option during configure, and that solved his problem. > >> > > >> > As this issue will probably take some time to get resolved across all the > >> > various Linux distros, it might be worth considering changing the default > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > >> > versions of the lib in the binary archive. > >> > > >> > Thanks for your indulgence > >> > > >> > Andy > >> > > >> > _______________________________________________ > >> > Rxtx mailing list > >> > Rxtx at qbang.org > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > >> > >> > >> > >> -- > >> Atte: > >> Daniel Dario Morales Salas > >> Ingeniero Civil en Computaci?n e Inform?tica > >> Tel?fono: 02 684 3417 > >> Celular: 09 643 1802 > >> Santiago, Chile > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > WWW: http://www.sharms.org/blog From damorales at gmail.com Wed Feb 3 18:26:38 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 22:26:38 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100204005829.7dc944e1@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: Hello I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva 2010 this is what i get: drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ and i don't have ANY problem with lock files and RXTX in my java software. All i had to do was add this rule to udev: # serial KERNEL=="tty*", GROUP="uucp", MODE="0666" and that was all. Of course my user (metalklesk) is part of uucp group. I did not make /var/lock writable to all users. Greetings ! 2010/2/3 Andy Eskelson > Thanks Steve, > > changing the serial ports back the uucp is not a big problem. I have a > udev rule that can be easily modified already. However I cannot see any > way of dealing with the var/lock problem apart from making it writable to > all. Any thoughts? > > Andy > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > wrote: > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > and is a result of unified udev rules. You can work around this by > > making udev change the group back to uucp until something more > > happens. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > Thanks, > > > > Steve > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > Thanks Daniel, > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > this for other programs for some time. > > > . > > > I don't think that this is the same problem. as far as I can understand > > > things, the lock files are written in var/lock. Previously var/lock and > > > dev/tty-whatever were the same group. Now with var/lock owned by and > with > > > a group of root:root anything other than root cannot create a lock > > > file. Even minicom is broken by this change. > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > Daniel Morales Salas wrote: > > > > > >> Hi > > >> > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > the uucp > > >> group did not work as it used to be in earlier versions of linux > distros, > > >> causing RXTX to not work as non root user. > > >> > > >> The problem appears because the existense of UDEV, now you MUST add a > RULE > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > the > > >> Serial Port. > > >> > > >> To solve the problem, without needing to recompile RXTX, you must add > a rule > > >> to grant permissions (0666) to the group for the device or port (tty*, > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > i > > >> come back home i will give it to you (i am at work now). > > >> > > >> Greetings ! > > >> > > >> 2010/2/3 > > >> > > >> > Hello RXTX group, > > >> > > > >> > I have just joined this group, and this is my first posting. > > >> > I wanted to pass on some information regarding rxtx, so apologies > if > > >> > this has been brought up before. I have searched back through the > > >> > archives but nothing specific came up. > > >> > > > >> > I am not a Java programmer, and I only came across rxtx a few days > ago. > > >> > > > >> > I use a piece of test equipment called a miniVNA > > >> > http://www.miniradiosolutions.com/ > > >> > > > >> > This is a serial USB controlled instrument, and it has control > software > > >> > available for MS windows, and a very old and now non-working Linux > > >> > application. > > >> > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > control the > > >> > miniVNA, obviously this application makes use of rxtx. > > >> > > > >> > The program worked fine on Windows, so I set about installing it > onto > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > running > > >> > fairly easily, sorting out the file locking by adding the uucp group > to > > >> > the users account as suggested (I used the 2.2pre binary files) I > then > > >> > passed the install instructions onto another miniVNA user, who also > uses > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > >> > also having file lock problems, but the uucp fix did not work. > Digging > > >> > into his system I found that there have been some changes in SUSE > 11.2. > > >> > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > >> > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > >> > checked, so: > > >> > > > >> > SUSE 11.1, var/lock is root:uucp > > >> > SUSE 11.2 var/lock is root:root > > >> > > > >> > A search on Google brought up several comments regarding this, and > also > > >> > a bugzilla entry. > > >> > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > >> > > > >> > However from reading the various posts, some of which are in the > bugzilla > > >> > entry, it appears that many distros may be, or have changed to this > > >> > configuration, and this will undoubtedly break several things, rxtx > > >> > included. > > >> > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > with the > > >> > no lock file option during configure, and that solved his problem. > > >> > > > >> > As this issue will probably take some time to get resolved across > all the > > >> > various Linux distros, it might be worth considering changing the > default > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > >> > versions of the lib in the binary archive. > > >> > > > >> > Thanks for your indulgence > > >> > > > >> > Andy > > >> > > > >> > _______________________________________________ > > >> > Rxtx mailing list > > >> > Rxtx at qbang.org > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > >> > > > >> > > >> > > >> > > >> -- > > >> Atte: > > >> Daniel Dario Morales Salas > > >> Ingeniero Civil en Computaci?n e Inform?tica > > >> Tel?fono: 02 684 3417 > > >> Celular: 09 643 1802 > > >> Santiago, Chile > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at qbang.org > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > -- > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > WWW: http://www.sharms.org/blog > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Thu Feb 4 05:31:46 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 12:31:46 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: <20100204123146.6cffeb67@workstation.site> Thank's for the confirmation. Something odd is going on somewhere in SUSE 11.2. I'll have to build up a local SUSE11.2 system to see if I can nail down exactly what is going on. Something is blocking the lockfiles in var/lock. The net is nice, but it's a bit difficult trying to work out what is going on what the machine in question is in Germany and I'm in the UK :-) Andy On Wed, 3 Feb 2010 22:26:38 -0300 Daniel Morales Salas wrote: > Hello > > I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva > 2010 this is what i get: > > drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ > > and i don't have ANY problem with lock files and RXTX in my java software. > All i had to do was add this rule to udev: > > # serial > KERNEL=="tty*", GROUP="uucp", MODE="0666" > > and that was all. Of course my user (metalklesk) is part of uucp group. > I did not make /var/lock writable to all users. > > Greetings ! > > 2010/2/3 Andy Eskelson > > > Thanks Steve, > > > > changing the serial ports back the uucp is not a big problem. I have a > > udev rule that can be easily modified already. However I cannot see any > > way of dealing with the var/lock problem apart from making it writable to > > all. Any thoughts? > > > > Andy > > > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > > wrote: > > > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > > and is a result of unified udev rules. You can work around this by > > > making udev change the group back to uucp until something more > > > happens. > > > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > > > Thanks, > > > > > > Steve > > > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > > Thanks Daniel, > > > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > > this for other programs for some time. > > > > . > > > > I don't think that this is the same problem. as far as I can understand > > > > things, the lock files are written in var/lock. Previously var/lock and > > > > dev/tty-whatever were the same group. Now with var/lock owned by and > > with > > > > a group of root:root anything other than root cannot create a lock > > > > file. Even minicom is broken by this change. > > > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > > Daniel Morales Salas wrote: > > > > > > > >> Hi > > > >> > > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > > the uucp > > > >> group did not work as it used to be in earlier versions of linux > > distros, > > > >> causing RXTX to not work as non root user. > > > >> > > > >> The problem appears because the existense of UDEV, now you MUST add a > > RULE > > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > > the > > > >> Serial Port. > > > >> > > > >> To solve the problem, without needing to recompile RXTX, you must add > > a rule > > > >> to grant permissions (0666) to the group for the device or port (tty*, > > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > > i > > > >> come back home i will give it to you (i am at work now). > > > >> > > > >> Greetings ! > > > >> > > > >> 2010/2/3 > > > >> > > > >> > Hello RXTX group, > > > >> > > > > >> > I have just joined this group, and this is my first posting. > > > >> > I wanted to pass on some information regarding rxtx, so apologies > > if > > > >> > this has been brought up before. I have searched back through the > > > >> > archives but nothing specific came up. > > > >> > > > > >> > I am not a Java programmer, and I only came across rxtx a few days > > ago. > > > >> > > > > >> > I use a piece of test equipment called a miniVNA > > > >> > http://www.miniradiosolutions.com/ > > > >> > > > > >> > This is a serial USB controlled instrument, and it has control > > software > > > >> > available for MS windows, and a very old and now non-working Linux > > > >> > application. > > > >> > > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > > control the > > > >> > miniVNA, obviously this application makes use of rxtx. > > > >> > > > > >> > The program worked fine on Windows, so I set about installing it > > onto > > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > > running > > > >> > fairly easily, sorting out the file locking by adding the uucp group > > to > > > >> > the users account as suggested (I used the 2.2pre binary files) I > > then > > > >> > passed the install instructions onto another miniVNA user, who also > > uses > > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > > >> > also having file lock problems, but the uucp fix did not work. > > Digging > > > >> > into his system I found that there have been some changes in SUSE > > 11.2. > > > >> > > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > > >> > > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > > >> > checked, so: > > > >> > > > > >> > SUSE 11.1, var/lock is root:uucp > > > >> > SUSE 11.2 var/lock is root:root > > > >> > > > > >> > A search on Google brought up several comments regarding this, and > > also > > > >> > a bugzilla entry. > > > >> > > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > >> > > > > >> > However from reading the various posts, some of which are in the > > bugzilla > > > >> > entry, it appears that many distros may be, or have changed to this > > > >> > configuration, and this will undoubtedly break several things, rxtx > > > >> > included. > > > >> > > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > > with the > > > >> > no lock file option during configure, and that solved his problem. > > > >> > > > > >> > As this issue will probably take some time to get resolved across > > all the > > > >> > various Linux distros, it might be worth considering changing the > > default > > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > > >> > versions of the lib in the binary archive. > > > >> > > > > >> > Thanks for your indulgence > > > >> > > > > >> > Andy > > > >> > > > > >> > _______________________________________________ > > > >> > Rxtx mailing list > > > >> > Rxtx at qbang.org > > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > > >> > > > > >> > > > >> > > > >> > > > >> -- > > > >> Atte: > > > >> Daniel Dario Morales Salas > > > >> Ingeniero Civil en Computaci?n e Inform?tica > > > >> Tel?fono: 02 684 3417 > > > >> Celular: 09 643 1802 > > > >> Santiago, Chile > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at qbang.org > > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > > > -- > > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > > > WWW: http://www.sharms.org/blog > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From Bob_Jacobsen at lbl.gov Thu Feb 4 09:26:49 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Thu, 4 Feb 2010 08:26:49 -0800 Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 Message-ID: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're using RXTX-2.2pre2, although it emits the known message about "Version mismatch". WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 After the usual messing around, we've got it working on 11 Windows versions, multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ have things working rarely say so, so I don't know whether anybody has gotten it to work on 10.4 or not. The problem encountered is this: dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib dyld: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib followed by the JVM crashing hard. I've got those dump files if that would help. Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If so, is there a patch I can get and build? Thanks Bob -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From tjarvi at qbang.org Thu Feb 4 14:22:21 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 4 Feb 2010 14:22:21 -0700 (MST) Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 In-Reply-To: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> References: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> Message-ID: On Thu, 4 Feb 2010, Bob Jacobsen wrote: > We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're > using RXTX-2.2pre2, although it emits the known message about "Version > mismatch". > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > > After the usual messing around, we've got it working on 11 Windows versions, > multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with > a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ > have things working rarely say so, so I don't know whether anybody has gotten > it to work on 10.4 or not. > > The problem encountered is this: > > dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > dyld: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > followed by the JVM crashing hard. I've got those dump files if that would > help. > > Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If > so, is there a patch I can get and build? > Hi Bob, I talked to a coworker about the problem you ran into. It appears that it is possible to target 'older' Mac systems through makefile configuration changes. "Configuring a Makefile-Based Project If you have a makefile-based project, you can also take advantage of SDK-based development, by adding the appropriate options to your compile and link commands. Using SDKs in makefile-based projects requires GCC 4.0 or later. To choose an SDK, you use the -isysroot option with the compiler and the -syslibroot option with the linker. Both options require that you specify the full path to the desired SDK directory. To set the Deployment OS version in a makefile, use a makefile variable of the form: ENVP= MACOSX_DEPLOYMENT_TARGET=10.4. To use this variable in your makefile, include it in front of your compile and link commands." http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html Or build on the oldest system you want to support. -- Trent Jarvi tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Thu Feb 4 14:56:19 2010 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Thu, 4 Feb 2010 14:56:19 -0700 Subject: [Rxtx] RXTX on 64 Bit Redhat In-Reply-To: References: <4ec9eab61001281448g3dd84910r867619948a4e0d7a@mail.gmail.com> Message-ID: Trent -- Finally fixed all my build related issues. I ran into another issue. On one of my machines my JDK is returning multiple folders for the "java.ext.dirs" (java.ext.dirs -> /opt/jdk1.6.0_17/jre/lib/ext:/usr/java/packages/lib/ext) system property. As a result my JVM wasn't able to detect the gnu.io.rxtx.properties. I am attaching a patch for RXTXCommDriver.java file to check for multiple locations. Also i have to assign permission 660 to all my dev ports to be located by RXTX. Pawan ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 5:12 PM To: Trent Jarvi Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Here is the error i get when i build the src from release-2-1-7 -bash-3.2$ make ( \ \ cd i686-pc-linux-gnu; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/ jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I/opt/jav a1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec - c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialImp.lo;\ if [ "Serial" = "Serial" ]; then \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I /opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_tim espec -c /home/jb_stg/rxtx/rxtx-devel/./src/fuserImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ else \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo; \ fi; \ ) gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/inclu de -I/opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need _timespec -c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -fPIC -DPIC -o /hom e/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/.libs/SerialImp.o /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:25:29: error: gnu_io_RXTXPort.h: No such file or directory In file included from /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:113: /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:91: error: expected specifier-qua lifier-list before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'jobject' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:408: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:409: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:410: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:411: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:415: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:416: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:417: error: expected '=', ',', '; ', 'asm' or '__attribute__' before 'is_interrupted' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:418: error: expected declaration specifiers or '...' before 'jint' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:424: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:441: error: expected ')' before ' *' token ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 4:57 PM To: Santosh Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Santosh -- Thank you. That fixed the issue. All -- What CVS branch or release should i use to get the latest RXTX src code. Pawan ________________________________ From: Santosh [mailto:santosh.ry at gmail.com] Sent: Thursday, January 28, 2010 3:49 PM To: Kharbanda, Pawan Cc: Trent Jarvi; rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat error "./configure: /bin/sh^M: bad interpreter: No such file or directory". I think you need to run dos2unix on script files before compiling. Thanks, Santosh On Thu, Jan 28, 2010 at 5:33 PM, Kharbanda, Pawan > wrote: Trent -- We are upgrading our exisiting OS and JDK on a project that rely heavily on RXTX api's. We are now using JDK1.6 32 bit (build 1.6.0_17-b04) and RedHat 5 on a 64 bit machine. Linux tocrhstg02.dot.state.co.us 2.6.18-164.6.1.el5 #1 SMP Tue Oct 27 11:30:06 EDT 2009 i686 i686 i386 GNU/Linux Red Hat Enterprise Linux Server release 5.4 (Tikanga) I tried to run version 2.1.7 r2 on it but not able to see any of my Digi ports I was able to access only /dev/ttyS0 (physical ports). Not sure if the problem is with the Digi driver or RXTX. I tried to open a Digi port with minicom and it worked fine. I also tried to get latest from CVS (rxtx-devel) and when I do "configure" I see this error "./configure: /bin/sh^M: bad interpreter: No such file or directory". Can someone please help me with this? Thanks for the help. Pawan _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch.txt URL: From juan.vicente.l.g at gmail.com Sat Feb 13 04:44:17 2010 From: juan.vicente.l.g at gmail.com (Juan Vicente Lopez Gutierrez) Date: Sat, 13 Feb 2010 12:44:17 +0100 Subject: [Rxtx] RXTX in macmini OSX 10.5 Message-ID: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> Hello. My name is Juanvi and I'm from Spain. I tried to launch a software created by me in the library CXR java to send information through the serial port and I can not make it work. In windows if I've done but not mac. I have a mac mini with OSX 10.5 and have read in the list of web mail that you CXR if you have managed to make it work on that operating system. I need you help me please. Do I make the mistake that shows me java: run: Stable Library =============================== Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 gnu.io.PortInUseException: Unknow Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:26) at TwoWatSerialComm.main(TwoWaySerialComm.java:106) Experimental: JNI_OnLoad called. GENERACION CORRECTA (total time: 0 seconds) I do not have permission to access the serial port, do not know. Os agradeceria much to sit down. A greeting and thanks. Pardon my English. Juanvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From juan.vicente.l.g at gmail.com Sat Feb 13 14:39:41 2010 From: juan.vicente.l.g at gmail.com (Juan Vicente Lopez Gutierrez) Date: Sat, 13 Feb 2010 22:39:41 +0100 Subject: [Rxtx] Fwd: RXTX in macmini OSX 10.5 In-Reply-To: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> References: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> Message-ID: <29405e5c1002131339m2059d169sdc8549ed9706a1af@mail.gmail.com> ---------- Forwarded message ---------- From: Juan Vicente Lopez Gutierrez Date: 2010/2/13 Subject: RXTX in macmini OSX 10.5 To: rxtx at qbang.org Hello. My name is Juanvi and I'm from Spain. I tried to launch a software created by me in the library CXR java to send information through the serial port and I can not make it work. In windows if I've done but not mac. I have a mac mini with OSX 10.5 and have read in the list of web mail that you CXR if you have managed to make it work on that operating system. I need you help me please. Do I make the mistake that shows me java: run: Stable Library =============================== Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 gnu.io.PortInUseException: Unknow Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:26) at TwoWatSerialComm.main(TwoWaySerialComm.java:106) Experimental: JNI_OnLoad called. GENERACION CORRECTA (total time: 0 seconds) I do not have permission to access the serial port, do not know. Os agradeceria much to sit down. A greeting and thanks. Pardon my English. Juanvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 01:02:21 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 13:32:21 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> My serial port driver(apparently) does not support receive timeout.I registered an event listener for DATA_AVAILABLE. However, the control never seems to come out of the 'while' loop.Shouldn't the InputStream.read return a '-1' immediately if no data is available (this seems to be the default operation)? This was tried on a x86 Linux desktop using rxtx-2.1-7 I've added the snippet for clarity: /******************************************************************************************************************************************************************************/ mySerialPort.enableReceiveThreshold(2000);//Trying to set a time limit for read calls System.out.println(mySerialPort.isReceiveTimeoutEnabled()); // I get FALSE, so its not supported on hardware. mySerialPort.addEventListener(this); mySerialPort.notifyOnDataAvailable(true);//register a event with //my SerialEvent listener implementation: public void serialEvent(SerialPortEvent arg0) { int newData=0; switch(arg0.getEventType()){ case SerialPortEvent.DATA_AVAILABLE: while (newData != -1) { try { newData = is.read();//This should eventually return a -1 if no data is available within a timeout.PROBLEM!! System.out.println("Got a byte from port:"+newData); if (newData == -1) { break; } } catch (IOException ex) { System.err.println(ex); return; } } break; } return; } /******************************************************************************************************************************************************************************/ Thanks and regards, Ravi From michael.erskine at ketech.com Wed Feb 3 02:26:50 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 09:26:50 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From michael.erskine at ketech.com Wed Feb 3 05:03:30 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 12:03:30 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > Michael Erskine > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > > Your event handler should handle the event and return immediately so that its > controlling thread can handle other events. I recommend a single read in the > following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) > reads all available bytes up to the size of the buffer returning the number of > bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } After posting this I considered the glaring possibility of the rawbuf read buffer being too small to receive all the available bytes and perhaps skipping data: after all, I'm guessing that is why we see so many posts asking for help with blocking implementations of read event handlers looping on "while(bytes are available)". I've spent this morning writing an extensive multi-threaded unit test suite that includes tests with a tiny buffer compared to the amount of data available and found that no data was being skipped. I now want to know why! The SerialPortEvent.DATA_AVAILABLE event must be being fired again if there is more data available on the input stream. If that is the case then it should be heavily documented with good examples in the wiki to avoid the types of developer anguish we see so regularly. BTW: I'm not at liberty to post the JUnit tests as they use my company's unit test suite framework. Regards, Michael Erskine. From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 06:18:04 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 18:48:04 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Hello Michael, I tried out your suggestion but the problem is that the read(rawbuf) blocks until the entire length of the rawbuf array has been read (blocking). I cannot decide on a reasonable size of the array because it varies from 2 bytes to as much as 50 byes (i'm communicating with a modem,each response is of a different length), which is why i wanted to use non blocking calls. But on a side note, read(byte[]) in turn calls the read() in a loop.In the native C function, the read is supposed to return a -1 upon timeout.But my driver does not support timeout.The default timeout value is zero and the linux select call upon zero time out causes an infinite wait.What am i missing...... Thanks and regards, Ravi Date: Wed, 3 Feb 2010 09:26:50 +0000 From: Michael Erskine To: "rxtx at qbang.org" Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: Content-Type: text/plain; charset="us-ascii" > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From m.kirkland at comcast.net Wed Feb 3 06:46:03 2010 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 3 Feb 2010 05:46:03 -0800 Subject: [Rxtx] One port blocking another port In-Reply-To: References: Message-ID: <68768633814F4D7D86761D34F0764FE0@bengal.net> It turns out this is caused by having the RTS/CTS flow control turned on and me not providing a true on the RTS pin. Somehow it seems the port timing out on a read allows the write to proceed. This is not an issue for my application but I wonder if the write should not proceed until the RTS pin is true even if a read times out. mk -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Monday, January 25, 2010 7:48 PM To: Mike Kirkland Cc: rxtx at qbang.org Subject: Re: [Rxtx] One port blocking another port On Mon, 25 Jan 2010, Mike Kirkland wrote: > > Hi All, > > ? > > I have a program that reads from one com port and writes to another com > port. It also does the same thing in reverse (reads from the second com port > and writes to the first one. It basically ties two com ports together. > > ? > > One port is very chatty and has a consent stream of data. The other port has > very little data. > > ? > > Both ports use a 5000 ms (5 second) time out. > > ? > > The issue I am having is that is appears that the first port?s write to the > second port is blocked while the second port is waiting for input. The first > port?s write proceeds only after the second port has timed out. > > ? > > I suppose I could have something twisted around in my code but I was > wondering if this is a know issue? > Hi Kirk, I've not seen a report like this. Perhaps some simple reproduction code will reveal a problem on your end or help us identify a problem in rxtx. I think there are several users doing multiport communication. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Wed Feb 3 07:03:58 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:03:58 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Message-ID: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> 2010/2/3 Ravishankar N > Hello Michael, > [..] > But on a side note, read(byte[]) in turn calls the read() in a loop.In the > native C function, the read is supposed to return a -1 upon timeout.But my > driver > does not support timeout.The default timeout value is zero and the linux > select call upon zero time out causes an infinite wait.What am i > missing...... > > When I have tested RXTX between platforms, I have observed "hangup" inside JNI driver when no data in Linux, is normal thing. Solution was setting the timeout for RXTX when no data from JNI driver. Something like that: commPort.enableReceiveTimeout(10); And it works perfect.... The only difference is that I am NOT using events - I am using continous read in separate thread and if data is available, is parsed and transferred to application using exception. Regards Mariusz > Thanks and regards, > Ravi > > Date: Wed, 3 Feb 2010 09:26:50 +0000 > From: Michael Erskine > To: "rxtx at qbang.org" > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > Message-ID: > > > Content-Type: text/plain; charset="us-ascii" > > > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of > > Ravishankar N > > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > > > My serial port driver(apparently) does not support receive timeout.I > > registered an event listener for DATA_AVAILABLE. However, the control > never > > seems to come out of the 'while' loop.Shouldn't the > > InputStream.read return a '-1' immediately if no data is available (this > seems > > to be the default operation)? > > Your event handler should handle the event and return immediately so that > its controlling thread can handle other events. I recommend a single read in > the following manner: rawbuf is a byte[] of "reasonable" size and the > read(byte[]) reads all available bytes up to the size of the buffer > returning the number of bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } > > This style of reading has worked for me with RXTX on Linux and Windows XP > for a good few years now in railway industry communications systems. Any > timeouts (largely unnecessary in my applications) can be handled elsewhere, > usually at a higher layer. > > Regards, > Michael Erskine. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Feb 3 07:22:55 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 3 Feb 2010 09:22:55 -0500 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: I'm guessing that this is driver specific. I recently had to support a select()/poll() infrastructure for a linux serial DD, its certainly non trivial to support async IO, so I suspect the problem in this case has to do with missing poll infrastructure in the device driver. This also has to coupled with special open flags for the device (which is within the rxtx code) The key routines within a 2.6 kernel linux device driver are shown below (if you have access to it for your particular device) are indicated below (here is a snippet from my device driver c code that supports polling/select). User space code to test this shown below also, note that the device needs to be opened with the O_NONBLOCK option to support the select/poll api // device driver code ..... /* * File operations supported by this driver. */ static struct file_operations iop_fops = { .owner = THIS_MODULE, .check_flags= iop_check_flags, .ioctl = iop_ioctl, .open = iop_open, .poll = iop_poll, // SUPPORT FOR SELECT/POLL infrastructure .read = iop_read, .release = iop_release, .write = iop_write, }; /** * Select/poll/epoll infrastructure. * * @param file * @param wait * * @return */ static unsigned int iop_poll(struct file *filp, poll_table *wait) { struct iop_device *devp = (struct iop_device *)filp->private_data; // the poll_table wait arg is an opaque pointer poll_wait(filp, &devp->readq, wait); // return from poll indicating whether we have read/write data unsigned int mask = 0; if (kfifo_len(devp->rx_fifo)) { mask |= (POLLIN | POLLRDNORM); } // @JC We don't do select on write yet // if (kfifo_len(devp->tx_fifo)) { // mask |= (POLLOUT | POLLWRNORM); // } // Only print out while debugging // if (mask != 0) { // printk (KERN_INFO "%s: [%04x]\n", __FUNCTION__, mask); // } return mask; } /** * device driver blocking and non blocking read function. This * function reads the requested number of bytes from the read * kfifo blocking as required. * * @param filp * @param buf * @param count * @param f_pos * * @return */ static ssize_t iop_read(struct file *filp, char __user *buf, size_t count, loff_t * ppos) { // access appropriate device struct struct iop_device *devp = (struct iop_device *) filp->private_data; ssize_t retval; // support non blocking mode (default) by checking if the kfifo is empty first if ((kfifo_len(devp->rx_fifo)==0) && (filp->f_flags & O_NONBLOCK)) { return -EAGAIN; } // wait for rx_fifo to receive data via receive interrupts retval = wait_event_interruptible(devp->readq, kfifo_len(devp->rx_fifo) != 0); // check for some error condition if (retval) { printk (KERN_ERR "%s: wait_event_interruptible returned[%d]\n", __FUNCTION__, retval); return retval; } // copy max requested bytes from rx_fifo to device buffer // this may still leave bytes in the kfifo for a subsequent read // if we are reading in a loop retval = kfifo_get(devp->rx_fifo, devp->rxbuf, count); // printk (KERN_INFO "%s: [%d] byte(s)\n", __FUNCTION__, retval); if (copy_to_user(buf, devp->rxbuf, retval)) { printk (KERN_ERR "%s: problem copying rx_fifo data to user buffer\n", __FUNCTION__); return -EFAULT; } return retval; } // a selection of my user space code reading via select()/poll()..... // user space open code iop_fd = ::open( deviceName.data(), O_RDWR | O_NONBLOCK); while ((bytes_to_expect - bytes_read) > 0) { // must reinitialize these between select calls fd_set readfds; FD_ZERO( &readfds ); FD_SET( iop_fd, &readfds ); // 1s sec read polling timeout struct timeval timeout; timeout.tv_sec = 1; timeout.tv_usec = 0; int rc = select( FD_SETSIZE, &readfds, NULL, NULL, &timeout ); // read from file when descriptor // indicates data available without blocking if ((rc > 0) && FD_ISSET(iop_fd, &readfds)) { // read into the appropriate offset within the rx_buf int temp = read(iop_fd, rx_buf + bytes_read, bytes_to_expect - bytes_read); if (!temp) { printf("EOF detected with %d bytes expected\n", bytes_to_expect - bytes_read); } else { bytes_read += temp; } } else if (rc < 0){ printf("%s: select on [%s], bytes_read[%d], errno=%d\n", __FUNCTION__, thread_args->device, bytes_read, errno); } else { printf("%s: select on [%s], bytes_read[%d], timeout\n", __FUNCTION__, thread_args->device, bytes_read); } } On Wed, Feb 3, 2010 at 9:03 AM, Mariusz Dec wrote: > > > 2010/2/3 Ravishankar N > >> Hello Michael, >> [..] >> >> But on a side note, read(byte[]) in turn calls the read() in a loop.In the >> native C function, the read is supposed to return a -1 upon timeout.But my >> driver >> does not support timeout.The default timeout value is zero and the linux >> select call upon zero time out causes an infinite wait.What am i >> missing...... >> >> > When I have tested RXTX between platforms, I have observed "hangup" inside > JNI driver when no data in Linux, is normal thing. > > Solution was setting the timeout for RXTX when no data from JNI driver. > > Something like that: > > commPort.enableReceiveTimeout(10); > > And it works perfect.... > > The only difference is that I am NOT using events - I am using continous > read in separate thread and if data is available, is parsed and transferred > to application using exception. > > Regards > Mariusz > > > >> Thanks and regards, >> Ravi >> >> Date: Wed, 3 Feb 2010 09:26:50 +0000 >> From: Michael Erskine >> To: "rxtx at qbang.org" >> Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? >> Message-ID: >> >> >> Content-Type: text/plain; charset="us-ascii" >> >> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >> Of >> > Ravishankar N >> > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? >> > >> > My serial port driver(apparently) does not support receive timeout.I >> > registered an event listener for DATA_AVAILABLE. However, the control >> never >> > seems to come out of the 'while' loop.Shouldn't the >> > InputStream.read return a '-1' immediately if no data is available (this >> seems >> > to be the default operation)? >> >> Your event handler should handle the event and return immediately so that >> its controlling thread can handle other events. I recommend a single read in >> the following manner: rawbuf is a byte[] of "reasonable" size and the >> read(byte[]) reads all available bytes up to the size of the buffer >> returning the number of bytes actually read... >> >> case SerialPortEvent.DATA_AVAILABLE: >> try { >> int i = is.read(rawbuf); >> if (i == -1) { >> << process EOF condition - should never happen >> >> return; >> } >> << process bytes (rawbuf, i); >> >> return; >> } catch (IOException e) { >> << promptly deal with exception >> >> return; >> } >> >> This style of reading has worked for me with RXTX on Linux and Windows XP >> for a good few years now in railway industry communications systems. Any >> timeouts (largely unnecessary in my applications) can be handled elsewhere, >> usually at a higher layer. >> >> Regards, >> Michael Erskine. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Feb 3 07:33:27 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:33:27 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: <73a89f361002030633j682610afia48dc7accd8e049b@mail.gmail.com> 2010/2/3 John Coffey > I'm guessing that this is driver specific. I recently had to support a > select()/poll() infrastructure for a linux serial DD, its certainly non > trivial to support async IO, so I suspect the problem in this case has to do > with missing poll infrastructure in the device driver. This also has to > coupled with special open flags for the device (which is within the rxtx > code) > > Yes, you are right, it may be driver specific, but in my case I haven't changed blocking JNI driver. I have added ONLY one call to RXTX method mentioned in my previous post and blocking (as seen as from Java app) gone out... Maybe this is not elegant, but works without problem in my app. I am using only FTDI chips and their drivers from couple of years and maybe this is the kind of the way to have no many problems with serial as well? Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From andyrxtx at g0poy.co.uk Wed Feb 3 11:09:04 2010 From: andyrxtx at g0poy.co.uk (andyrxtx at g0poy.co.uk) Date: Wed, 3 Feb 2010 18:09:04 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes Message-ID: <20100203180904.164f24dd@workstation.site> ?Hello RXTX group, I have just joined this group, and this is my first posting. I wanted to pass on some information regarding rxtx, so apologies if this has been brought up before. I have searched back through the archives but nothing specific came up. I am not a Java programmer, and I only came across rxtx a few days ago. I use a piece of test equipment called a miniVNA http://www.miniradiosolutions.com/ This is a serial USB controlled instrument, and it has control software available for MS windows, and a very old and now non-working Linux application. A few days ago Dietmar, DL2SBA released a Java application to control the miniVNA, obviously this application makes use of rxtx. The program worked fine on Windows, so I set about installing it onto Linux. I use SUSE11.1 After a few false starts, I got the system running fairly easily, sorting out the file locking by adding the uucp group to the users account as suggested (I used the 2.2pre binary files) I then passed the install instructions onto another miniVNA user, who also uses SUSE, but he ran into problems. To cut a long story short, he was also having file lock problems, but the uucp fix did not work. Digging into his system I found that there have been some changes in SUSE 11.2. tty ports are now assigned to the dialout group rather than uucp. A hint in the rxtx INSTALL file, suggested that var/lock needs to be checked, so: SUSE 11.1, var/lock is root:uucp SUSE 11.2 var/lock is root:root A search on Google brought up several comments regarding this, and also a bugzilla entry. https://bugzilla.novell.com/show_bug.cgi?id=552095 However from reading the various posts, some of which are in the bugzilla entry, it appears that many distros may be, or have changed to this configuration, and this will undoubtedly break several things, rxtx included. I solved my fellow SUSE users problem by compiling the rxtx libs with the no lock file option during configure, and that solved his problem. As this issue will probably take some time to get resolved across all the various Linux distros, it might be worth considering changing the default on the Linux build of rxtx not to use lockfiles, or provide the two versions of the lib in the binary archive. Thanks for your indulgence Andy From damorales at gmail.com Wed Feb 3 11:33:23 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 15:33:23 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203180904.164f24dd@workstation.site> References: <20100203180904.164f24dd@workstation.site> Message-ID: Hi I had the same problem in Mandriva 2010 and yes, adding the user to the uucp group did not work as it used to be in earlier versions of linux distros, causing RXTX to not work as non root user. The problem appears because the existense of UDEV, now you MUST add a RULE so the group (uucp or whatever) have access (Read, Write, Execute) to the Serial Port. To solve the problem, without needing to recompile RXTX, you must add a rule to grant permissions (0666) to the group for the device or port (tty*, ttyUSB*, etc). I do not remember now what is the line i added but when i come back home i will give it to you (i am at work now). Greetings ! 2010/2/3 > Hello RXTX group, > > I have just joined this group, and this is my first posting. > I wanted to pass on some information regarding rxtx, so apologies if > this has been brought up before. I have searched back through the > archives but nothing specific came up. > > I am not a Java programmer, and I only came across rxtx a few days ago. > > I use a piece of test equipment called a miniVNA > http://www.miniradiosolutions.com/ > > This is a serial USB controlled instrument, and it has control software > available for MS windows, and a very old and now non-working Linux > application. > > A few days ago Dietmar, DL2SBA released a Java application to control the > miniVNA, obviously this application makes use of rxtx. > > The program worked fine on Windows, so I set about installing it onto > Linux. I use SUSE11.1 After a few false starts, I got the system running > fairly easily, sorting out the file locking by adding the uucp group to > the users account as suggested (I used the 2.2pre binary files) I then > passed the install instructions onto another miniVNA user, who also uses > SUSE, but he ran into problems. To cut a long story short, he was > also having file lock problems, but the uucp fix did not work. Digging > into his system I found that there have been some changes in SUSE 11.2. > > tty ports are now assigned to the dialout group rather than uucp. > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > checked, so: > > SUSE 11.1, var/lock is root:uucp > SUSE 11.2 var/lock is root:root > > A search on Google brought up several comments regarding this, and also > a bugzilla entry. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > However from reading the various posts, some of which are in the bugzilla > entry, it appears that many distros may be, or have changed to this > configuration, and this will undoubtedly break several things, rxtx > included. > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > no lock file option during configure, and that solved his problem. > > As this issue will probably take some time to get resolved across all the > various Linux distros, it might be worth considering changing the default > on the Linux build of rxtx not to use lockfiles, or provide the two > versions of the lib in the binary archive. > > Thanks for your indulgence > > Andy > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Wed Feb 3 12:07:02 2010 From: andy at g0poy.com (Andy Eskelson) Date: Wed, 3 Feb 2010 19:07:02 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> Message-ID: <20100203190702.1b0e7015@workstation.site> Thanks Daniel, I am aware of the permissions problem, I have had a udev rules to solve this for other programs for some time. . I don't think that this is the same problem. as far as I can understand things, the lock files are written in var/lock. Previously var/lock and dev/tty-whatever were the same group. Now with var/lock owned by and with a group of root:root anything other than root cannot create a lock file. Even minicom is broken by this change. This change is going to have quite a few knock-on effects I think. Andy On Wed, 3 Feb 2010 15:33:23 -0300 Daniel Morales Salas wrote: > Hi > > I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > group did not work as it used to be in earlier versions of linux distros, > causing RXTX to not work as non root user. > > The problem appears because the existense of UDEV, now you MUST add a RULE > so the group (uucp or whatever) have access (Read, Write, Execute) to the > Serial Port. > > To solve the problem, without needing to recompile RXTX, you must add a rule > to grant permissions (0666) to the group for the device or port (tty*, > ttyUSB*, etc). I do not remember now what is the line i added but when i > come back home i will give it to you (i am at work now). > > Greetings ! > > 2010/2/3 > > > Hello RXTX group, > > > > I have just joined this group, and this is my first posting. > > I wanted to pass on some information regarding rxtx, so apologies if > > this has been brought up before. I have searched back through the > > archives but nothing specific came up. > > > > I am not a Java programmer, and I only came across rxtx a few days ago. > > > > I use a piece of test equipment called a miniVNA > > http://www.miniradiosolutions.com/ > > > > This is a serial USB controlled instrument, and it has control software > > available for MS windows, and a very old and now non-working Linux > > application. > > > > A few days ago Dietmar, DL2SBA released a Java application to control the > > miniVNA, obviously this application makes use of rxtx. > > > > The program worked fine on Windows, so I set about installing it onto > > Linux. I use SUSE11.1 After a few false starts, I got the system running > > fairly easily, sorting out the file locking by adding the uucp group to > > the users account as suggested (I used the 2.2pre binary files) I then > > passed the install instructions onto another miniVNA user, who also uses > > SUSE, but he ran into problems. To cut a long story short, he was > > also having file lock problems, but the uucp fix did not work. Digging > > into his system I found that there have been some changes in SUSE 11.2. > > > > tty ports are now assigned to the dialout group rather than uucp. > > > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > checked, so: > > > > SUSE 11.1, var/lock is root:uucp > > SUSE 11.2 var/lock is root:root > > > > A search on Google brought up several comments regarding this, and also > > a bugzilla entry. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > However from reading the various posts, some of which are in the bugzilla > > entry, it appears that many distros may be, or have changed to this > > configuration, and this will undoubtedly break several things, rxtx > > included. > > > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > > no lock file option during configure, and that solved his problem. > > > > As this issue will probably take some time to get resolved across all the > > various Linux distros, it might be worth considering changing the default > > on the Linux build of rxtx not to use lockfiles, or provide the two > > versions of the lib in the binary archive. > > > > Thanks for your indulgence > > > > Andy > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From thisdyingdream at gmail.com Wed Feb 3 12:32:35 2010 From: thisdyingdream at gmail.com (Steven Harms) Date: Wed, 3 Feb 2010 14:32:35 -0500 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203190702.1b0e7015@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: This is currently a bug in OpenSUSE that affects more than just rxtx, and is a result of unified udev rules. You can work around this by making udev change the group back to uucp until something more happens. https://bugzilla.novell.com/show_bug.cgi?id=552095 Thanks, Steve On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > Thanks Daniel, > > I am aware of the permissions problem, I have had a udev rules to solve > this for other programs for some time. > . > I don't think that this is the same problem. as far as I can understand > things, the lock files are written in var/lock. Previously var/lock and > dev/tty-whatever were the same group. Now with var/lock owned by and with > a group of root:root anything other than root cannot create a lock > file. Even minicom is broken by this change. > > This change is going to have quite a few knock-on effects I think. > > > Andy > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > Daniel Morales Salas wrote: > >> Hi >> >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp >> group did not work as it used to be in earlier versions of linux distros, >> causing RXTX to not work as non root user. >> >> The problem appears because the existense of UDEV, now you MUST add a RULE >> so the group (uucp or whatever) have access (Read, Write, Execute) to the >> Serial Port. >> >> To solve the problem, without needing to recompile RXTX, you must add a rule >> to grant permissions (0666) to the group for the device or port (tty*, >> ttyUSB*, etc). I do not remember now what is the line i added but when i >> come back home i will give it to you (i am at work now). >> >> Greetings ! >> >> 2010/2/3 >> >> > Hello RXTX group, >> > >> > I have just joined this group, and this is my first posting. >> > I wanted to pass on ?some information regarding rxtx, so apologies if >> > this has been brought up before. I have searched back through the >> > archives but nothing specific came up. >> > >> > I am not a Java programmer, and I only came across rxtx a few days ago. >> > >> > I use a piece of test equipment called a miniVNA >> > http://www.miniradiosolutions.com/ >> > >> > This is a serial USB controlled instrument, and it has control software >> > available for MS windows, and a very old and now non-working Linux >> > application. >> > >> > A few days ago Dietmar, DL2SBA released a Java application to control the >> > miniVNA, obviously this application makes use of rxtx. >> > >> > The program worked fine on Windows, so I set about installing it onto >> > Linux. I use SUSE11.1 After a few false starts, I got the system running >> > fairly easily, sorting out the file locking by adding the uucp group to >> > the users account as suggested (I used the 2.2pre binary files) I then >> > passed the install instructions onto another miniVNA user, who also uses >> > SUSE, but he ran into problems. To cut a long story short, he was >> > also having file lock problems, but the uucp fix did not work. Digging >> > into his system I found that there have been some changes in SUSE 11.2. >> > >> > tty ports are now assigned to the dialout group rather than uucp. >> > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be >> > checked, so: >> > >> > SUSE 11.1, var/lock is root:uucp >> > SUSE 11.2 var/lock is root:root >> > >> > A search on Google brought up several comments regarding this, and also >> > a ?bugzilla entry. >> > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 >> > >> > However from reading the various posts, some of which are in the bugzilla >> > entry, it appears that many distros may be, or have changed to this >> > configuration, and this will undoubtedly break several things, rxtx >> > included. >> > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the >> > no lock file option during configure, and that solved his problem. >> > >> > As this issue will probably take some time to get resolved across all the >> > various Linux distros, it might be worth considering changing the default >> > on the Linux build of rxtx not to use lockfiles, or provide the two >> > versions of the lib in the binary archive. >> > >> > Thanks for your indulgence >> > >> > Andy >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> >> >> >> -- >> Atte: >> Daniel Dario Morales Salas >> Ingeniero Civil en Computaci?n e Inform?tica >> Tel?fono: 02 684 3417 >> Celular: 09 643 1802 >> Santiago, Chile > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 WWW: http://www.sharms.org/blog From andy at g0poy.com Wed Feb 3 17:58:29 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 00:58:29 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: <20100204005829.7dc944e1@workstation.site> Thanks Steve, changing the serial ports back the uucp is not a big problem. I have a udev rule that can be easily modified already. However I cannot see any way of dealing with the var/lock problem apart from making it writable to all. Any thoughts? Andy On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms wrote: > This is currently a bug in OpenSUSE that affects more than just rxtx, > and is a result of unified udev rules. You can work around this by > making udev change the group back to uucp until something more > happens. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > Thanks, > > Steve > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > Thanks Daniel, > > > > I am aware of the permissions problem, I have had a udev rules to solve > > this for other programs for some time. > > . > > I don't think that this is the same problem. as far as I can understand > > things, the lock files are written in var/lock. Previously var/lock and > > dev/tty-whatever were the same group. Now with var/lock owned by and with > > a group of root:root anything other than root cannot create a lock > > file. Even minicom is broken by this change. > > > > This change is going to have quite a few knock-on effects I think. > > > > > > Andy > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > Daniel Morales Salas wrote: > > > >> Hi > >> > >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > >> group did not work as it used to be in earlier versions of linux distros, > >> causing RXTX to not work as non root user. > >> > >> The problem appears because the existense of UDEV, now you MUST add a RULE > >> so the group (uucp or whatever) have access (Read, Write, Execute) to the > >> Serial Port. > >> > >> To solve the problem, without needing to recompile RXTX, you must add a rule > >> to grant permissions (0666) to the group for the device or port (tty*, > >> ttyUSB*, etc). I do not remember now what is the line i added but when i > >> come back home i will give it to you (i am at work now). > >> > >> Greetings ! > >> > >> 2010/2/3 > >> > >> > Hello RXTX group, > >> > > >> > I have just joined this group, and this is my first posting. > >> > I wanted to pass on ?some information regarding rxtx, so apologies if > >> > this has been brought up before. I have searched back through the > >> > archives but nothing specific came up. > >> > > >> > I am not a Java programmer, and I only came across rxtx a few days ago. > >> > > >> > I use a piece of test equipment called a miniVNA > >> > http://www.miniradiosolutions.com/ > >> > > >> > This is a serial USB controlled instrument, and it has control software > >> > available for MS windows, and a very old and now non-working Linux > >> > application. > >> > > >> > A few days ago Dietmar, DL2SBA released a Java application to control the > >> > miniVNA, obviously this application makes use of rxtx. > >> > > >> > The program worked fine on Windows, so I set about installing it onto > >> > Linux. I use SUSE11.1 After a few false starts, I got the system running > >> > fairly easily, sorting out the file locking by adding the uucp group to > >> > the users account as suggested (I used the 2.2pre binary files) I then > >> > passed the install instructions onto another miniVNA user, who also uses > >> > SUSE, but he ran into problems. To cut a long story short, he was > >> > also having file lock problems, but the uucp fix did not work. Digging > >> > into his system I found that there have been some changes in SUSE 11.2. > >> > > >> > tty ports are now assigned to the dialout group rather than uucp. > >> > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > >> > checked, so: > >> > > >> > SUSE 11.1, var/lock is root:uucp > >> > SUSE 11.2 var/lock is root:root > >> > > >> > A search on Google brought up several comments regarding this, and also > >> > a ?bugzilla entry. > >> > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > >> > > >> > However from reading the various posts, some of which are in the bugzilla > >> > entry, it appears that many distros may be, or have changed to this > >> > configuration, and this will undoubtedly break several things, rxtx > >> > included. > >> > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the > >> > no lock file option during configure, and that solved his problem. > >> > > >> > As this issue will probably take some time to get resolved across all the > >> > various Linux distros, it might be worth considering changing the default > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > >> > versions of the lib in the binary archive. > >> > > >> > Thanks for your indulgence > >> > > >> > Andy > >> > > >> > _______________________________________________ > >> > Rxtx mailing list > >> > Rxtx at qbang.org > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > >> > >> > >> > >> -- > >> Atte: > >> Daniel Dario Morales Salas > >> Ingeniero Civil en Computaci?n e Inform?tica > >> Tel?fono: 02 684 3417 > >> Celular: 09 643 1802 > >> Santiago, Chile > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > WWW: http://www.sharms.org/blog From damorales at gmail.com Wed Feb 3 18:26:38 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 22:26:38 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100204005829.7dc944e1@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: Hello I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva 2010 this is what i get: drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ and i don't have ANY problem with lock files and RXTX in my java software. All i had to do was add this rule to udev: # serial KERNEL=="tty*", GROUP="uucp", MODE="0666" and that was all. Of course my user (metalklesk) is part of uucp group. I did not make /var/lock writable to all users. Greetings ! 2010/2/3 Andy Eskelson > Thanks Steve, > > changing the serial ports back the uucp is not a big problem. I have a > udev rule that can be easily modified already. However I cannot see any > way of dealing with the var/lock problem apart from making it writable to > all. Any thoughts? > > Andy > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > wrote: > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > and is a result of unified udev rules. You can work around this by > > making udev change the group back to uucp until something more > > happens. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > Thanks, > > > > Steve > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > Thanks Daniel, > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > this for other programs for some time. > > > . > > > I don't think that this is the same problem. as far as I can understand > > > things, the lock files are written in var/lock. Previously var/lock and > > > dev/tty-whatever were the same group. Now with var/lock owned by and > with > > > a group of root:root anything other than root cannot create a lock > > > file. Even minicom is broken by this change. > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > Daniel Morales Salas wrote: > > > > > >> Hi > > >> > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > the uucp > > >> group did not work as it used to be in earlier versions of linux > distros, > > >> causing RXTX to not work as non root user. > > >> > > >> The problem appears because the existense of UDEV, now you MUST add a > RULE > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > the > > >> Serial Port. > > >> > > >> To solve the problem, without needing to recompile RXTX, you must add > a rule > > >> to grant permissions (0666) to the group for the device or port (tty*, > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > i > > >> come back home i will give it to you (i am at work now). > > >> > > >> Greetings ! > > >> > > >> 2010/2/3 > > >> > > >> > Hello RXTX group, > > >> > > > >> > I have just joined this group, and this is my first posting. > > >> > I wanted to pass on some information regarding rxtx, so apologies > if > > >> > this has been brought up before. I have searched back through the > > >> > archives but nothing specific came up. > > >> > > > >> > I am not a Java programmer, and I only came across rxtx a few days > ago. > > >> > > > >> > I use a piece of test equipment called a miniVNA > > >> > http://www.miniradiosolutions.com/ > > >> > > > >> > This is a serial USB controlled instrument, and it has control > software > > >> > available for MS windows, and a very old and now non-working Linux > > >> > application. > > >> > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > control the > > >> > miniVNA, obviously this application makes use of rxtx. > > >> > > > >> > The program worked fine on Windows, so I set about installing it > onto > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > running > > >> > fairly easily, sorting out the file locking by adding the uucp group > to > > >> > the users account as suggested (I used the 2.2pre binary files) I > then > > >> > passed the install instructions onto another miniVNA user, who also > uses > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > >> > also having file lock problems, but the uucp fix did not work. > Digging > > >> > into his system I found that there have been some changes in SUSE > 11.2. > > >> > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > >> > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > >> > checked, so: > > >> > > > >> > SUSE 11.1, var/lock is root:uucp > > >> > SUSE 11.2 var/lock is root:root > > >> > > > >> > A search on Google brought up several comments regarding this, and > also > > >> > a bugzilla entry. > > >> > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > >> > > > >> > However from reading the various posts, some of which are in the > bugzilla > > >> > entry, it appears that many distros may be, or have changed to this > > >> > configuration, and this will undoubtedly break several things, rxtx > > >> > included. > > >> > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > with the > > >> > no lock file option during configure, and that solved his problem. > > >> > > > >> > As this issue will probably take some time to get resolved across > all the > > >> > various Linux distros, it might be worth considering changing the > default > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > >> > versions of the lib in the binary archive. > > >> > > > >> > Thanks for your indulgence > > >> > > > >> > Andy > > >> > > > >> > _______________________________________________ > > >> > Rxtx mailing list > > >> > Rxtx at qbang.org > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > >> > > > >> > > >> > > >> > > >> -- > > >> Atte: > > >> Daniel Dario Morales Salas > > >> Ingeniero Civil en Computaci?n e Inform?tica > > >> Tel?fono: 02 684 3417 > > >> Celular: 09 643 1802 > > >> Santiago, Chile > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at qbang.org > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > -- > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > WWW: http://www.sharms.org/blog > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Thu Feb 4 05:31:46 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 12:31:46 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: <20100204123146.6cffeb67@workstation.site> Thank's for the confirmation. Something odd is going on somewhere in SUSE 11.2. I'll have to build up a local SUSE11.2 system to see if I can nail down exactly what is going on. Something is blocking the lockfiles in var/lock. The net is nice, but it's a bit difficult trying to work out what is going on what the machine in question is in Germany and I'm in the UK :-) Andy On Wed, 3 Feb 2010 22:26:38 -0300 Daniel Morales Salas wrote: > Hello > > I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva > 2010 this is what i get: > > drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ > > and i don't have ANY problem with lock files and RXTX in my java software. > All i had to do was add this rule to udev: > > # serial > KERNEL=="tty*", GROUP="uucp", MODE="0666" > > and that was all. Of course my user (metalklesk) is part of uucp group. > I did not make /var/lock writable to all users. > > Greetings ! > > 2010/2/3 Andy Eskelson > > > Thanks Steve, > > > > changing the serial ports back the uucp is not a big problem. I have a > > udev rule that can be easily modified already. However I cannot see any > > way of dealing with the var/lock problem apart from making it writable to > > all. Any thoughts? > > > > Andy > > > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > > wrote: > > > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > > and is a result of unified udev rules. You can work around this by > > > making udev change the group back to uucp until something more > > > happens. > > > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > > > Thanks, > > > > > > Steve > > > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > > Thanks Daniel, > > > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > > this for other programs for some time. > > > > . > > > > I don't think that this is the same problem. as far as I can understand > > > > things, the lock files are written in var/lock. Previously var/lock and > > > > dev/tty-whatever were the same group. Now with var/lock owned by and > > with > > > > a group of root:root anything other than root cannot create a lock > > > > file. Even minicom is broken by this change. > > > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > > Daniel Morales Salas wrote: > > > > > > > >> Hi > > > >> > > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > > the uucp > > > >> group did not work as it used to be in earlier versions of linux > > distros, > > > >> causing RXTX to not work as non root user. > > > >> > > > >> The problem appears because the existense of UDEV, now you MUST add a > > RULE > > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > > the > > > >> Serial Port. > > > >> > > > >> To solve the problem, without needing to recompile RXTX, you must add > > a rule > > > >> to grant permissions (0666) to the group for the device or port (tty*, > > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > > i > > > >> come back home i will give it to you (i am at work now). > > > >> > > > >> Greetings ! > > > >> > > > >> 2010/2/3 > > > >> > > > >> > Hello RXTX group, > > > >> > > > > >> > I have just joined this group, and this is my first posting. > > > >> > I wanted to pass on some information regarding rxtx, so apologies > > if > > > >> > this has been brought up before. I have searched back through the > > > >> > archives but nothing specific came up. > > > >> > > > > >> > I am not a Java programmer, and I only came across rxtx a few days > > ago. > > > >> > > > > >> > I use a piece of test equipment called a miniVNA > > > >> > http://www.miniradiosolutions.com/ > > > >> > > > > >> > This is a serial USB controlled instrument, and it has control > > software > > > >> > available for MS windows, and a very old and now non-working Linux > > > >> > application. > > > >> > > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > > control the > > > >> > miniVNA, obviously this application makes use of rxtx. > > > >> > > > > >> > The program worked fine on Windows, so I set about installing it > > onto > > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > > running > > > >> > fairly easily, sorting out the file locking by adding the uucp group > > to > > > >> > the users account as suggested (I used the 2.2pre binary files) I > > then > > > >> > passed the install instructions onto another miniVNA user, who also > > uses > > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > > >> > also having file lock problems, but the uucp fix did not work. > > Digging > > > >> > into his system I found that there have been some changes in SUSE > > 11.2. > > > >> > > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > > >> > > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > > >> > checked, so: > > > >> > > > > >> > SUSE 11.1, var/lock is root:uucp > > > >> > SUSE 11.2 var/lock is root:root > > > >> > > > > >> > A search on Google brought up several comments regarding this, and > > also > > > >> > a bugzilla entry. > > > >> > > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > >> > > > > >> > However from reading the various posts, some of which are in the > > bugzilla > > > >> > entry, it appears that many distros may be, or have changed to this > > > >> > configuration, and this will undoubtedly break several things, rxtx > > > >> > included. > > > >> > > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > > with the > > > >> > no lock file option during configure, and that solved his problem. > > > >> > > > > >> > As this issue will probably take some time to get resolved across > > all the > > > >> > various Linux distros, it might be worth considering changing the > > default > > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > > >> > versions of the lib in the binary archive. > > > >> > > > > >> > Thanks for your indulgence > > > >> > > > > >> > Andy > > > >> > > > > >> > _______________________________________________ > > > >> > Rxtx mailing list > > > >> > Rxtx at qbang.org > > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > > >> > > > > >> > > > >> > > > >> > > > >> -- > > > >> Atte: > > > >> Daniel Dario Morales Salas > > > >> Ingeniero Civil en Computaci?n e Inform?tica > > > >> Tel?fono: 02 684 3417 > > > >> Celular: 09 643 1802 > > > >> Santiago, Chile > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at qbang.org > > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > > > -- > > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > > > WWW: http://www.sharms.org/blog > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From Bob_Jacobsen at lbl.gov Thu Feb 4 09:26:49 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Thu, 4 Feb 2010 08:26:49 -0800 Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 Message-ID: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're using RXTX-2.2pre2, although it emits the known message about "Version mismatch". WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 After the usual messing around, we've got it working on 11 Windows versions, multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ have things working rarely say so, so I don't know whether anybody has gotten it to work on 10.4 or not. The problem encountered is this: dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib dyld: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib followed by the JVM crashing hard. I've got those dump files if that would help. Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If so, is there a patch I can get and build? Thanks Bob -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From tjarvi at qbang.org Thu Feb 4 14:22:21 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 4 Feb 2010 14:22:21 -0700 (MST) Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 In-Reply-To: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> References: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> Message-ID: On Thu, 4 Feb 2010, Bob Jacobsen wrote: > We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're > using RXTX-2.2pre2, although it emits the known message about "Version > mismatch". > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > > After the usual messing around, we've got it working on 11 Windows versions, > multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with > a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ > have things working rarely say so, so I don't know whether anybody has gotten > it to work on 10.4 or not. > > The problem encountered is this: > > dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > dyld: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > followed by the JVM crashing hard. I've got those dump files if that would > help. > > Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If > so, is there a patch I can get and build? > Hi Bob, I talked to a coworker about the problem you ran into. It appears that it is possible to target 'older' Mac systems through makefile configuration changes. "Configuring a Makefile-Based Project If you have a makefile-based project, you can also take advantage of SDK-based development, by adding the appropriate options to your compile and link commands. Using SDKs in makefile-based projects requires GCC 4.0 or later. To choose an SDK, you use the -isysroot option with the compiler and the -syslibroot option with the linker. Both options require that you specify the full path to the desired SDK directory. To set the Deployment OS version in a makefile, use a makefile variable of the form: ENVP= MACOSX_DEPLOYMENT_TARGET=10.4. To use this variable in your makefile, include it in front of your compile and link commands." http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html Or build on the oldest system you want to support. -- Trent Jarvi tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Thu Feb 4 14:56:19 2010 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Thu, 4 Feb 2010 14:56:19 -0700 Subject: [Rxtx] RXTX on 64 Bit Redhat In-Reply-To: References: <4ec9eab61001281448g3dd84910r867619948a4e0d7a@mail.gmail.com> Message-ID: Trent -- Finally fixed all my build related issues. I ran into another issue. On one of my machines my JDK is returning multiple folders for the "java.ext.dirs" (java.ext.dirs -> /opt/jdk1.6.0_17/jre/lib/ext:/usr/java/packages/lib/ext) system property. As a result my JVM wasn't able to detect the gnu.io.rxtx.properties. I am attaching a patch for RXTXCommDriver.java file to check for multiple locations. Also i have to assign permission 660 to all my dev ports to be located by RXTX. Pawan ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 5:12 PM To: Trent Jarvi Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Here is the error i get when i build the src from release-2-1-7 -bash-3.2$ make ( \ \ cd i686-pc-linux-gnu; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/ jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I/opt/jav a1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec - c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialImp.lo;\ if [ "Serial" = "Serial" ]; then \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I /opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_tim espec -c /home/jb_stg/rxtx/rxtx-devel/./src/fuserImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ else \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo; \ fi; \ ) gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/inclu de -I/opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need _timespec -c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -fPIC -DPIC -o /hom e/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/.libs/SerialImp.o /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:25:29: error: gnu_io_RXTXPort.h: No such file or directory In file included from /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:113: /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:91: error: expected specifier-qua lifier-list before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'jobject' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:408: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:409: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:410: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:411: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:415: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:416: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:417: error: expected '=', ',', '; ', 'asm' or '__attribute__' before 'is_interrupted' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:418: error: expected declaration specifiers or '...' before 'jint' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:424: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:441: error: expected ')' before ' *' token ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 4:57 PM To: Santosh Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Santosh -- Thank you. That fixed the issue. All -- What CVS branch or release should i use to get the latest RXTX src code. Pawan ________________________________ From: Santosh [mailto:santosh.ry at gmail.com] Sent: Thursday, January 28, 2010 3:49 PM To: Kharbanda, Pawan Cc: Trent Jarvi; rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat error "./configure: /bin/sh^M: bad interpreter: No such file or directory". I think you need to run dos2unix on script files before compiling. Thanks, Santosh On Thu, Jan 28, 2010 at 5:33 PM, Kharbanda, Pawan > wrote: Trent -- We are upgrading our exisiting OS and JDK on a project that rely heavily on RXTX api's. We are now using JDK1.6 32 bit (build 1.6.0_17-b04) and RedHat 5 on a 64 bit machine. Linux tocrhstg02.dot.state.co.us 2.6.18-164.6.1.el5 #1 SMP Tue Oct 27 11:30:06 EDT 2009 i686 i686 i386 GNU/Linux Red Hat Enterprise Linux Server release 5.4 (Tikanga) I tried to run version 2.1.7 r2 on it but not able to see any of my Digi ports I was able to access only /dev/ttyS0 (physical ports). Not sure if the problem is with the Digi driver or RXTX. I tried to open a Digi port with minicom and it worked fine. I also tried to get latest from CVS (rxtx-devel) and when I do "configure" I see this error "./configure: /bin/sh^M: bad interpreter: No such file or directory". Can someone please help me with this? Thanks for the help. Pawan _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch.txt URL: From juan.vicente.l.g at gmail.com Sat Feb 13 04:44:17 2010 From: juan.vicente.l.g at gmail.com (Juan Vicente Lopez Gutierrez) Date: Sat, 13 Feb 2010 12:44:17 +0100 Subject: [Rxtx] RXTX in macmini OSX 10.5 Message-ID: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> Hello. My name is Juanvi and I'm from Spain. I tried to launch a software created by me in the library CXR java to send information through the serial port and I can not make it work. In windows if I've done but not mac. I have a mac mini with OSX 10.5 and have read in the list of web mail that you CXR if you have managed to make it work on that operating system. I need you help me please. Do I make the mistake that shows me java: run: Stable Library =============================== Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 gnu.io.PortInUseException: Unknow Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:26) at TwoWatSerialComm.main(TwoWaySerialComm.java:106) Experimental: JNI_OnLoad called. GENERACION CORRECTA (total time: 0 seconds) I do not have permission to access the serial port, do not know. Os agradeceria much to sit down. A greeting and thanks. Pardon my English. Juanvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From juan.vicente.l.g at gmail.com Sat Feb 13 14:39:41 2010 From: juan.vicente.l.g at gmail.com (Juan Vicente Lopez Gutierrez) Date: Sat, 13 Feb 2010 22:39:41 +0100 Subject: [Rxtx] Fwd: RXTX in macmini OSX 10.5 In-Reply-To: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> References: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> Message-ID: <29405e5c1002131339m2059d169sdc8549ed9706a1af@mail.gmail.com> ---------- Forwarded message ---------- From: Juan Vicente Lopez Gutierrez Date: 2010/2/13 Subject: RXTX in macmini OSX 10.5 To: rxtx at qbang.org Hello. My name is Juanvi and I'm from Spain. I tried to launch a software created by me in the library CXR java to send information through the serial port and I can not make it work. In windows if I've done but not mac. I have a mac mini with OSX 10.5 and have read in the list of web mail that you CXR if you have managed to make it work on that operating system. I need you help me please. Do I make the mistake that shows me java: run: Stable Library =============================== Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 gnu.io.PortInUseException: Unknow Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:26) at TwoWatSerialComm.main(TwoWaySerialComm.java:106) Experimental: JNI_OnLoad called. GENERACION CORRECTA (total time: 0 seconds) I do not have permission to access the serial port, do not know. Os agradeceria much to sit down. A greeting and thanks. Pardon my English. Juanvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 01:02:21 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 13:32:21 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> My serial port driver(apparently) does not support receive timeout.I registered an event listener for DATA_AVAILABLE. However, the control never seems to come out of the 'while' loop.Shouldn't the InputStream.read return a '-1' immediately if no data is available (this seems to be the default operation)? This was tried on a x86 Linux desktop using rxtx-2.1-7 I've added the snippet for clarity: /******************************************************************************************************************************************************************************/ mySerialPort.enableReceiveThreshold(2000);//Trying to set a time limit for read calls System.out.println(mySerialPort.isReceiveTimeoutEnabled()); // I get FALSE, so its not supported on hardware. mySerialPort.addEventListener(this); mySerialPort.notifyOnDataAvailable(true);//register a event with //my SerialEvent listener implementation: public void serialEvent(SerialPortEvent arg0) { int newData=0; switch(arg0.getEventType()){ case SerialPortEvent.DATA_AVAILABLE: while (newData != -1) { try { newData = is.read();//This should eventually return a -1 if no data is available within a timeout.PROBLEM!! System.out.println("Got a byte from port:"+newData); if (newData == -1) { break; } } catch (IOException ex) { System.err.println(ex); return; } } break; } return; } /******************************************************************************************************************************************************************************/ Thanks and regards, Ravi From michael.erskine at ketech.com Wed Feb 3 02:26:50 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 09:26:50 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From michael.erskine at ketech.com Wed Feb 3 05:03:30 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 12:03:30 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > Michael Erskine > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > > Your event handler should handle the event and return immediately so that its > controlling thread can handle other events. I recommend a single read in the > following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) > reads all available bytes up to the size of the buffer returning the number of > bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } After posting this I considered the glaring possibility of the rawbuf read buffer being too small to receive all the available bytes and perhaps skipping data: after all, I'm guessing that is why we see so many posts asking for help with blocking implementations of read event handlers looping on "while(bytes are available)". I've spent this morning writing an extensive multi-threaded unit test suite that includes tests with a tiny buffer compared to the amount of data available and found that no data was being skipped. I now want to know why! The SerialPortEvent.DATA_AVAILABLE event must be being fired again if there is more data available on the input stream. If that is the case then it should be heavily documented with good examples in the wiki to avoid the types of developer anguish we see so regularly. BTW: I'm not at liberty to post the JUnit tests as they use my company's unit test suite framework. Regards, Michael Erskine. From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 06:18:04 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 18:48:04 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Hello Michael, I tried out your suggestion but the problem is that the read(rawbuf) blocks until the entire length of the rawbuf array has been read (blocking). I cannot decide on a reasonable size of the array because it varies from 2 bytes to as much as 50 byes (i'm communicating with a modem,each response is of a different length), which is why i wanted to use non blocking calls. But on a side note, read(byte[]) in turn calls the read() in a loop.In the native C function, the read is supposed to return a -1 upon timeout.But my driver does not support timeout.The default timeout value is zero and the linux select call upon zero time out causes an infinite wait.What am i missing...... Thanks and regards, Ravi Date: Wed, 3 Feb 2010 09:26:50 +0000 From: Michael Erskine To: "rxtx at qbang.org" Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: Content-Type: text/plain; charset="us-ascii" > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From m.kirkland at comcast.net Wed Feb 3 06:46:03 2010 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 3 Feb 2010 05:46:03 -0800 Subject: [Rxtx] One port blocking another port In-Reply-To: References: Message-ID: <68768633814F4D7D86761D34F0764FE0@bengal.net> It turns out this is caused by having the RTS/CTS flow control turned on and me not providing a true on the RTS pin. Somehow it seems the port timing out on a read allows the write to proceed. This is not an issue for my application but I wonder if the write should not proceed until the RTS pin is true even if a read times out. mk -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Monday, January 25, 2010 7:48 PM To: Mike Kirkland Cc: rxtx at qbang.org Subject: Re: [Rxtx] One port blocking another port On Mon, 25 Jan 2010, Mike Kirkland wrote: > > Hi All, > > ? > > I have a program that reads from one com port and writes to another com > port. It also does the same thing in reverse (reads from the second com port > and writes to the first one. It basically ties two com ports together. > > ? > > One port is very chatty and has a consent stream of data. The other port has > very little data. > > ? > > Both ports use a 5000 ms (5 second) time out. > > ? > > The issue I am having is that is appears that the first port?s write to the > second port is blocked while the second port is waiting for input. The first > port?s write proceeds only after the second port has timed out. > > ? > > I suppose I could have something twisted around in my code but I was > wondering if this is a know issue? > Hi Kirk, I've not seen a report like this. Perhaps some simple reproduction code will reveal a problem on your end or help us identify a problem in rxtx. I think there are several users doing multiport communication. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Wed Feb 3 07:03:58 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:03:58 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Message-ID: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> 2010/2/3 Ravishankar N > Hello Michael, > [..] > But on a side note, read(byte[]) in turn calls the read() in a loop.In the > native C function, the read is supposed to return a -1 upon timeout.But my > driver > does not support timeout.The default timeout value is zero and the linux > select call upon zero time out causes an infinite wait.What am i > missing...... > > When I have tested RXTX between platforms, I have observed "hangup" inside JNI driver when no data in Linux, is normal thing. Solution was setting the timeout for RXTX when no data from JNI driver. Something like that: commPort.enableReceiveTimeout(10); And it works perfect.... The only difference is that I am NOT using events - I am using continous read in separate thread and if data is available, is parsed and transferred to application using exception. Regards Mariusz > Thanks and regards, > Ravi > > Date: Wed, 3 Feb 2010 09:26:50 +0000 > From: Michael Erskine > To: "rxtx at qbang.org" > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > Message-ID: > > > Content-Type: text/plain; charset="us-ascii" > > > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of > > Ravishankar N > > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > > > My serial port driver(apparently) does not support receive timeout.I > > registered an event listener for DATA_AVAILABLE. However, the control > never > > seems to come out of the 'while' loop.Shouldn't the > > InputStream.read return a '-1' immediately if no data is available (this > seems > > to be the default operation)? > > Your event handler should handle the event and return immediately so that > its controlling thread can handle other events. I recommend a single read in > the following manner: rawbuf is a byte[] of "reasonable" size and the > read(byte[]) reads all available bytes up to the size of the buffer > returning the number of bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } > > This style of reading has worked for me with RXTX on Linux and Windows XP > for a good few years now in railway industry communications systems. Any > timeouts (largely unnecessary in my applications) can be handled elsewhere, > usually at a higher layer. > > Regards, > Michael Erskine. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Feb 3 07:22:55 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 3 Feb 2010 09:22:55 -0500 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: I'm guessing that this is driver specific. I recently had to support a select()/poll() infrastructure for a linux serial DD, its certainly non trivial to support async IO, so I suspect the problem in this case has to do with missing poll infrastructure in the device driver. This also has to coupled with special open flags for the device (which is within the rxtx code) The key routines within a 2.6 kernel linux device driver are shown below (if you have access to it for your particular device) are indicated below (here is a snippet from my device driver c code that supports polling/select). User space code to test this shown below also, note that the device needs to be opened with the O_NONBLOCK option to support the select/poll api // device driver code ..... /* * File operations supported by this driver. */ static struct file_operations iop_fops = { .owner = THIS_MODULE, .check_flags= iop_check_flags, .ioctl = iop_ioctl, .open = iop_open, .poll = iop_poll, // SUPPORT FOR SELECT/POLL infrastructure .read = iop_read, .release = iop_release, .write = iop_write, }; /** * Select/poll/epoll infrastructure. * * @param file * @param wait * * @return */ static unsigned int iop_poll(struct file *filp, poll_table *wait) { struct iop_device *devp = (struct iop_device *)filp->private_data; // the poll_table wait arg is an opaque pointer poll_wait(filp, &devp->readq, wait); // return from poll indicating whether we have read/write data unsigned int mask = 0; if (kfifo_len(devp->rx_fifo)) { mask |= (POLLIN | POLLRDNORM); } // @JC We don't do select on write yet // if (kfifo_len(devp->tx_fifo)) { // mask |= (POLLOUT | POLLWRNORM); // } // Only print out while debugging // if (mask != 0) { // printk (KERN_INFO "%s: [%04x]\n", __FUNCTION__, mask); // } return mask; } /** * device driver blocking and non blocking read function. This * function reads the requested number of bytes from the read * kfifo blocking as required. * * @param filp * @param buf * @param count * @param f_pos * * @return */ static ssize_t iop_read(struct file *filp, char __user *buf, size_t count, loff_t * ppos) { // access appropriate device struct struct iop_device *devp = (struct iop_device *) filp->private_data; ssize_t retval; // support non blocking mode (default) by checking if the kfifo is empty first if ((kfifo_len(devp->rx_fifo)==0) && (filp->f_flags & O_NONBLOCK)) { return -EAGAIN; } // wait for rx_fifo to receive data via receive interrupts retval = wait_event_interruptible(devp->readq, kfifo_len(devp->rx_fifo) != 0); // check for some error condition if (retval) { printk (KERN_ERR "%s: wait_event_interruptible returned[%d]\n", __FUNCTION__, retval); return retval; } // copy max requested bytes from rx_fifo to device buffer // this may still leave bytes in the kfifo for a subsequent read // if we are reading in a loop retval = kfifo_get(devp->rx_fifo, devp->rxbuf, count); // printk (KERN_INFO "%s: [%d] byte(s)\n", __FUNCTION__, retval); if (copy_to_user(buf, devp->rxbuf, retval)) { printk (KERN_ERR "%s: problem copying rx_fifo data to user buffer\n", __FUNCTION__); return -EFAULT; } return retval; } // a selection of my user space code reading via select()/poll()..... // user space open code iop_fd = ::open( deviceName.data(), O_RDWR | O_NONBLOCK); while ((bytes_to_expect - bytes_read) > 0) { // must reinitialize these between select calls fd_set readfds; FD_ZERO( &readfds ); FD_SET( iop_fd, &readfds ); // 1s sec read polling timeout struct timeval timeout; timeout.tv_sec = 1; timeout.tv_usec = 0; int rc = select( FD_SETSIZE, &readfds, NULL, NULL, &timeout ); // read from file when descriptor // indicates data available without blocking if ((rc > 0) && FD_ISSET(iop_fd, &readfds)) { // read into the appropriate offset within the rx_buf int temp = read(iop_fd, rx_buf + bytes_read, bytes_to_expect - bytes_read); if (!temp) { printf("EOF detected with %d bytes expected\n", bytes_to_expect - bytes_read); } else { bytes_read += temp; } } else if (rc < 0){ printf("%s: select on [%s], bytes_read[%d], errno=%d\n", __FUNCTION__, thread_args->device, bytes_read, errno); } else { printf("%s: select on [%s], bytes_read[%d], timeout\n", __FUNCTION__, thread_args->device, bytes_read); } } On Wed, Feb 3, 2010 at 9:03 AM, Mariusz Dec wrote: > > > 2010/2/3 Ravishankar N > >> Hello Michael, >> [..] >> >> But on a side note, read(byte[]) in turn calls the read() in a loop.In the >> native C function, the read is supposed to return a -1 upon timeout.But my >> driver >> does not support timeout.The default timeout value is zero and the linux >> select call upon zero time out causes an infinite wait.What am i >> missing...... >> >> > When I have tested RXTX between platforms, I have observed "hangup" inside > JNI driver when no data in Linux, is normal thing. > > Solution was setting the timeout for RXTX when no data from JNI driver. > > Something like that: > > commPort.enableReceiveTimeout(10); > > And it works perfect.... > > The only difference is that I am NOT using events - I am using continous > read in separate thread and if data is available, is parsed and transferred > to application using exception. > > Regards > Mariusz > > > >> Thanks and regards, >> Ravi >> >> Date: Wed, 3 Feb 2010 09:26:50 +0000 >> From: Michael Erskine >> To: "rxtx at qbang.org" >> Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? >> Message-ID: >> >> >> Content-Type: text/plain; charset="us-ascii" >> >> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >> Of >> > Ravishankar N >> > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? >> > >> > My serial port driver(apparently) does not support receive timeout.I >> > registered an event listener for DATA_AVAILABLE. However, the control >> never >> > seems to come out of the 'while' loop.Shouldn't the >> > InputStream.read return a '-1' immediately if no data is available (this >> seems >> > to be the default operation)? >> >> Your event handler should handle the event and return immediately so that >> its controlling thread can handle other events. I recommend a single read in >> the following manner: rawbuf is a byte[] of "reasonable" size and the >> read(byte[]) reads all available bytes up to the size of the buffer >> returning the number of bytes actually read... >> >> case SerialPortEvent.DATA_AVAILABLE: >> try { >> int i = is.read(rawbuf); >> if (i == -1) { >> << process EOF condition - should never happen >> >> return; >> } >> << process bytes (rawbuf, i); >> >> return; >> } catch (IOException e) { >> << promptly deal with exception >> >> return; >> } >> >> This style of reading has worked for me with RXTX on Linux and Windows XP >> for a good few years now in railway industry communications systems. Any >> timeouts (largely unnecessary in my applications) can be handled elsewhere, >> usually at a higher layer. >> >> Regards, >> Michael Erskine. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Feb 3 07:33:27 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:33:27 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: <73a89f361002030633j682610afia48dc7accd8e049b@mail.gmail.com> 2010/2/3 John Coffey > I'm guessing that this is driver specific. I recently had to support a > select()/poll() infrastructure for a linux serial DD, its certainly non > trivial to support async IO, so I suspect the problem in this case has to do > with missing poll infrastructure in the device driver. This also has to > coupled with special open flags for the device (which is within the rxtx > code) > > Yes, you are right, it may be driver specific, but in my case I haven't changed blocking JNI driver. I have added ONLY one call to RXTX method mentioned in my previous post and blocking (as seen as from Java app) gone out... Maybe this is not elegant, but works without problem in my app. I am using only FTDI chips and their drivers from couple of years and maybe this is the kind of the way to have no many problems with serial as well? Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From andyrxtx at g0poy.co.uk Wed Feb 3 11:09:04 2010 From: andyrxtx at g0poy.co.uk (andyrxtx at g0poy.co.uk) Date: Wed, 3 Feb 2010 18:09:04 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes Message-ID: <20100203180904.164f24dd@workstation.site> ?Hello RXTX group, I have just joined this group, and this is my first posting. I wanted to pass on some information regarding rxtx, so apologies if this has been brought up before. I have searched back through the archives but nothing specific came up. I am not a Java programmer, and I only came across rxtx a few days ago. I use a piece of test equipment called a miniVNA http://www.miniradiosolutions.com/ This is a serial USB controlled instrument, and it has control software available for MS windows, and a very old and now non-working Linux application. A few days ago Dietmar, DL2SBA released a Java application to control the miniVNA, obviously this application makes use of rxtx. The program worked fine on Windows, so I set about installing it onto Linux. I use SUSE11.1 After a few false starts, I got the system running fairly easily, sorting out the file locking by adding the uucp group to the users account as suggested (I used the 2.2pre binary files) I then passed the install instructions onto another miniVNA user, who also uses SUSE, but he ran into problems. To cut a long story short, he was also having file lock problems, but the uucp fix did not work. Digging into his system I found that there have been some changes in SUSE 11.2. tty ports are now assigned to the dialout group rather than uucp. A hint in the rxtx INSTALL file, suggested that var/lock needs to be checked, so: SUSE 11.1, var/lock is root:uucp SUSE 11.2 var/lock is root:root A search on Google brought up several comments regarding this, and also a bugzilla entry. https://bugzilla.novell.com/show_bug.cgi?id=552095 However from reading the various posts, some of which are in the bugzilla entry, it appears that many distros may be, or have changed to this configuration, and this will undoubtedly break several things, rxtx included. I solved my fellow SUSE users problem by compiling the rxtx libs with the no lock file option during configure, and that solved his problem. As this issue will probably take some time to get resolved across all the various Linux distros, it might be worth considering changing the default on the Linux build of rxtx not to use lockfiles, or provide the two versions of the lib in the binary archive. Thanks for your indulgence Andy From damorales at gmail.com Wed Feb 3 11:33:23 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 15:33:23 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203180904.164f24dd@workstation.site> References: <20100203180904.164f24dd@workstation.site> Message-ID: Hi I had the same problem in Mandriva 2010 and yes, adding the user to the uucp group did not work as it used to be in earlier versions of linux distros, causing RXTX to not work as non root user. The problem appears because the existense of UDEV, now you MUST add a RULE so the group (uucp or whatever) have access (Read, Write, Execute) to the Serial Port. To solve the problem, without needing to recompile RXTX, you must add a rule to grant permissions (0666) to the group for the device or port (tty*, ttyUSB*, etc). I do not remember now what is the line i added but when i come back home i will give it to you (i am at work now). Greetings ! 2010/2/3 > Hello RXTX group, > > I have just joined this group, and this is my first posting. > I wanted to pass on some information regarding rxtx, so apologies if > this has been brought up before. I have searched back through the > archives but nothing specific came up. > > I am not a Java programmer, and I only came across rxtx a few days ago. > > I use a piece of test equipment called a miniVNA > http://www.miniradiosolutions.com/ > > This is a serial USB controlled instrument, and it has control software > available for MS windows, and a very old and now non-working Linux > application. > > A few days ago Dietmar, DL2SBA released a Java application to control the > miniVNA, obviously this application makes use of rxtx. > > The program worked fine on Windows, so I set about installing it onto > Linux. I use SUSE11.1 After a few false starts, I got the system running > fairly easily, sorting out the file locking by adding the uucp group to > the users account as suggested (I used the 2.2pre binary files) I then > passed the install instructions onto another miniVNA user, who also uses > SUSE, but he ran into problems. To cut a long story short, he was > also having file lock problems, but the uucp fix did not work. Digging > into his system I found that there have been some changes in SUSE 11.2. > > tty ports are now assigned to the dialout group rather than uucp. > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > checked, so: > > SUSE 11.1, var/lock is root:uucp > SUSE 11.2 var/lock is root:root > > A search on Google brought up several comments regarding this, and also > a bugzilla entry. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > However from reading the various posts, some of which are in the bugzilla > entry, it appears that many distros may be, or have changed to this > configuration, and this will undoubtedly break several things, rxtx > included. > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > no lock file option during configure, and that solved his problem. > > As this issue will probably take some time to get resolved across all the > various Linux distros, it might be worth considering changing the default > on the Linux build of rxtx not to use lockfiles, or provide the two > versions of the lib in the binary archive. > > Thanks for your indulgence > > Andy > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Wed Feb 3 12:07:02 2010 From: andy at g0poy.com (Andy Eskelson) Date: Wed, 3 Feb 2010 19:07:02 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> Message-ID: <20100203190702.1b0e7015@workstation.site> Thanks Daniel, I am aware of the permissions problem, I have had a udev rules to solve this for other programs for some time. . I don't think that this is the same problem. as far as I can understand things, the lock files are written in var/lock. Previously var/lock and dev/tty-whatever were the same group. Now with var/lock owned by and with a group of root:root anything other than root cannot create a lock file. Even minicom is broken by this change. This change is going to have quite a few knock-on effects I think. Andy On Wed, 3 Feb 2010 15:33:23 -0300 Daniel Morales Salas wrote: > Hi > > I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > group did not work as it used to be in earlier versions of linux distros, > causing RXTX to not work as non root user. > > The problem appears because the existense of UDEV, now you MUST add a RULE > so the group (uucp or whatever) have access (Read, Write, Execute) to the > Serial Port. > > To solve the problem, without needing to recompile RXTX, you must add a rule > to grant permissions (0666) to the group for the device or port (tty*, > ttyUSB*, etc). I do not remember now what is the line i added but when i > come back home i will give it to you (i am at work now). > > Greetings ! > > 2010/2/3 > > > Hello RXTX group, > > > > I have just joined this group, and this is my first posting. > > I wanted to pass on some information regarding rxtx, so apologies if > > this has been brought up before. I have searched back through the > > archives but nothing specific came up. > > > > I am not a Java programmer, and I only came across rxtx a few days ago. > > > > I use a piece of test equipment called a miniVNA > > http://www.miniradiosolutions.com/ > > > > This is a serial USB controlled instrument, and it has control software > > available for MS windows, and a very old and now non-working Linux > > application. > > > > A few days ago Dietmar, DL2SBA released a Java application to control the > > miniVNA, obviously this application makes use of rxtx. > > > > The program worked fine on Windows, so I set about installing it onto > > Linux. I use SUSE11.1 After a few false starts, I got the system running > > fairly easily, sorting out the file locking by adding the uucp group to > > the users account as suggested (I used the 2.2pre binary files) I then > > passed the install instructions onto another miniVNA user, who also uses > > SUSE, but he ran into problems. To cut a long story short, he was > > also having file lock problems, but the uucp fix did not work. Digging > > into his system I found that there have been some changes in SUSE 11.2. > > > > tty ports are now assigned to the dialout group rather than uucp. > > > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > checked, so: > > > > SUSE 11.1, var/lock is root:uucp > > SUSE 11.2 var/lock is root:root > > > > A search on Google brought up several comments regarding this, and also > > a bugzilla entry. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > However from reading the various posts, some of which are in the bugzilla > > entry, it appears that many distros may be, or have changed to this > > configuration, and this will undoubtedly break several things, rxtx > > included. > > > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > > no lock file option during configure, and that solved his problem. > > > > As this issue will probably take some time to get resolved across all the > > various Linux distros, it might be worth considering changing the default > > on the Linux build of rxtx not to use lockfiles, or provide the two > > versions of the lib in the binary archive. > > > > Thanks for your indulgence > > > > Andy > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From thisdyingdream at gmail.com Wed Feb 3 12:32:35 2010 From: thisdyingdream at gmail.com (Steven Harms) Date: Wed, 3 Feb 2010 14:32:35 -0500 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203190702.1b0e7015@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: This is currently a bug in OpenSUSE that affects more than just rxtx, and is a result of unified udev rules. You can work around this by making udev change the group back to uucp until something more happens. https://bugzilla.novell.com/show_bug.cgi?id=552095 Thanks, Steve On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > Thanks Daniel, > > I am aware of the permissions problem, I have had a udev rules to solve > this for other programs for some time. > . > I don't think that this is the same problem. as far as I can understand > things, the lock files are written in var/lock. Previously var/lock and > dev/tty-whatever were the same group. Now with var/lock owned by and with > a group of root:root anything other than root cannot create a lock > file. Even minicom is broken by this change. > > This change is going to have quite a few knock-on effects I think. > > > Andy > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > Daniel Morales Salas wrote: > >> Hi >> >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp >> group did not work as it used to be in earlier versions of linux distros, >> causing RXTX to not work as non root user. >> >> The problem appears because the existense of UDEV, now you MUST add a RULE >> so the group (uucp or whatever) have access (Read, Write, Execute) to the >> Serial Port. >> >> To solve the problem, without needing to recompile RXTX, you must add a rule >> to grant permissions (0666) to the group for the device or port (tty*, >> ttyUSB*, etc). I do not remember now what is the line i added but when i >> come back home i will give it to you (i am at work now). >> >> Greetings ! >> >> 2010/2/3 >> >> > Hello RXTX group, >> > >> > I have just joined this group, and this is my first posting. >> > I wanted to pass on ?some information regarding rxtx, so apologies if >> > this has been brought up before. I have searched back through the >> > archives but nothing specific came up. >> > >> > I am not a Java programmer, and I only came across rxtx a few days ago. >> > >> > I use a piece of test equipment called a miniVNA >> > http://www.miniradiosolutions.com/ >> > >> > This is a serial USB controlled instrument, and it has control software >> > available for MS windows, and a very old and now non-working Linux >> > application. >> > >> > A few days ago Dietmar, DL2SBA released a Java application to control the >> > miniVNA, obviously this application makes use of rxtx. >> > >> > The program worked fine on Windows, so I set about installing it onto >> > Linux. I use SUSE11.1 After a few false starts, I got the system running >> > fairly easily, sorting out the file locking by adding the uucp group to >> > the users account as suggested (I used the 2.2pre binary files) I then >> > passed the install instructions onto another miniVNA user, who also uses >> > SUSE, but he ran into problems. To cut a long story short, he was >> > also having file lock problems, but the uucp fix did not work. Digging >> > into his system I found that there have been some changes in SUSE 11.2. >> > >> > tty ports are now assigned to the dialout group rather than uucp. >> > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be >> > checked, so: >> > >> > SUSE 11.1, var/lock is root:uucp >> > SUSE 11.2 var/lock is root:root >> > >> > A search on Google brought up several comments regarding this, and also >> > a ?bugzilla entry. >> > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 >> > >> > However from reading the various posts, some of which are in the bugzilla >> > entry, it appears that many distros may be, or have changed to this >> > configuration, and this will undoubtedly break several things, rxtx >> > included. >> > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the >> > no lock file option during configure, and that solved his problem. >> > >> > As this issue will probably take some time to get resolved across all the >> > various Linux distros, it might be worth considering changing the default >> > on the Linux build of rxtx not to use lockfiles, or provide the two >> > versions of the lib in the binary archive. >> > >> > Thanks for your indulgence >> > >> > Andy >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> >> >> >> -- >> Atte: >> Daniel Dario Morales Salas >> Ingeniero Civil en Computaci?n e Inform?tica >> Tel?fono: 02 684 3417 >> Celular: 09 643 1802 >> Santiago, Chile > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 WWW: http://www.sharms.org/blog From andy at g0poy.com Wed Feb 3 17:58:29 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 00:58:29 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: <20100204005829.7dc944e1@workstation.site> Thanks Steve, changing the serial ports back the uucp is not a big problem. I have a udev rule that can be easily modified already. However I cannot see any way of dealing with the var/lock problem apart from making it writable to all. Any thoughts? Andy On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms wrote: > This is currently a bug in OpenSUSE that affects more than just rxtx, > and is a result of unified udev rules. You can work around this by > making udev change the group back to uucp until something more > happens. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > Thanks, > > Steve > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > Thanks Daniel, > > > > I am aware of the permissions problem, I have had a udev rules to solve > > this for other programs for some time. > > . > > I don't think that this is the same problem. as far as I can understand > > things, the lock files are written in var/lock. Previously var/lock and > > dev/tty-whatever were the same group. Now with var/lock owned by and with > > a group of root:root anything other than root cannot create a lock > > file. Even minicom is broken by this change. > > > > This change is going to have quite a few knock-on effects I think. > > > > > > Andy > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > Daniel Morales Salas wrote: > > > >> Hi > >> > >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > >> group did not work as it used to be in earlier versions of linux distros, > >> causing RXTX to not work as non root user. > >> > >> The problem appears because the existense of UDEV, now you MUST add a RULE > >> so the group (uucp or whatever) have access (Read, Write, Execute) to the > >> Serial Port. > >> > >> To solve the problem, without needing to recompile RXTX, you must add a rule > >> to grant permissions (0666) to the group for the device or port (tty*, > >> ttyUSB*, etc). I do not remember now what is the line i added but when i > >> come back home i will give it to you (i am at work now). > >> > >> Greetings ! > >> > >> 2010/2/3 > >> > >> > Hello RXTX group, > >> > > >> > I have just joined this group, and this is my first posting. > >> > I wanted to pass on ?some information regarding rxtx, so apologies if > >> > this has been brought up before. I have searched back through the > >> > archives but nothing specific came up. > >> > > >> > I am not a Java programmer, and I only came across rxtx a few days ago. > >> > > >> > I use a piece of test equipment called a miniVNA > >> > http://www.miniradiosolutions.com/ > >> > > >> > This is a serial USB controlled instrument, and it has control software > >> > available for MS windows, and a very old and now non-working Linux > >> > application. > >> > > >> > A few days ago Dietmar, DL2SBA released a Java application to control the > >> > miniVNA, obviously this application makes use of rxtx. > >> > > >> > The program worked fine on Windows, so I set about installing it onto > >> > Linux. I use SUSE11.1 After a few false starts, I got the system running > >> > fairly easily, sorting out the file locking by adding the uucp group to > >> > the users account as suggested (I used the 2.2pre binary files) I then > >> > passed the install instructions onto another miniVNA user, who also uses > >> > SUSE, but he ran into problems. To cut a long story short, he was > >> > also having file lock problems, but the uucp fix did not work. Digging > >> > into his system I found that there have been some changes in SUSE 11.2. > >> > > >> > tty ports are now assigned to the dialout group rather than uucp. > >> > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > >> > checked, so: > >> > > >> > SUSE 11.1, var/lock is root:uucp > >> > SUSE 11.2 var/lock is root:root > >> > > >> > A search on Google brought up several comments regarding this, and also > >> > a ?bugzilla entry. > >> > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > >> > > >> > However from reading the various posts, some of which are in the bugzilla > >> > entry, it appears that many distros may be, or have changed to this > >> > configuration, and this will undoubtedly break several things, rxtx > >> > included. > >> > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the > >> > no lock file option during configure, and that solved his problem. > >> > > >> > As this issue will probably take some time to get resolved across all the > >> > various Linux distros, it might be worth considering changing the default > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > >> > versions of the lib in the binary archive. > >> > > >> > Thanks for your indulgence > >> > > >> > Andy > >> > > >> > _______________________________________________ > >> > Rxtx mailing list > >> > Rxtx at qbang.org > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > >> > >> > >> > >> -- > >> Atte: > >> Daniel Dario Morales Salas > >> Ingeniero Civil en Computaci?n e Inform?tica > >> Tel?fono: 02 684 3417 > >> Celular: 09 643 1802 > >> Santiago, Chile > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > WWW: http://www.sharms.org/blog From damorales at gmail.com Wed Feb 3 18:26:38 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 22:26:38 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100204005829.7dc944e1@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: Hello I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva 2010 this is what i get: drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ and i don't have ANY problem with lock files and RXTX in my java software. All i had to do was add this rule to udev: # serial KERNEL=="tty*", GROUP="uucp", MODE="0666" and that was all. Of course my user (metalklesk) is part of uucp group. I did not make /var/lock writable to all users. Greetings ! 2010/2/3 Andy Eskelson > Thanks Steve, > > changing the serial ports back the uucp is not a big problem. I have a > udev rule that can be easily modified already. However I cannot see any > way of dealing with the var/lock problem apart from making it writable to > all. Any thoughts? > > Andy > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > wrote: > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > and is a result of unified udev rules. You can work around this by > > making udev change the group back to uucp until something more > > happens. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > Thanks, > > > > Steve > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > Thanks Daniel, > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > this for other programs for some time. > > > . > > > I don't think that this is the same problem. as far as I can understand > > > things, the lock files are written in var/lock. Previously var/lock and > > > dev/tty-whatever were the same group. Now with var/lock owned by and > with > > > a group of root:root anything other than root cannot create a lock > > > file. Even minicom is broken by this change. > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > Daniel Morales Salas wrote: > > > > > >> Hi > > >> > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > the uucp > > >> group did not work as it used to be in earlier versions of linux > distros, > > >> causing RXTX to not work as non root user. > > >> > > >> The problem appears because the existense of UDEV, now you MUST add a > RULE > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > the > > >> Serial Port. > > >> > > >> To solve the problem, without needing to recompile RXTX, you must add > a rule > > >> to grant permissions (0666) to the group for the device or port (tty*, > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > i > > >> come back home i will give it to you (i am at work now). > > >> > > >> Greetings ! > > >> > > >> 2010/2/3 > > >> > > >> > Hello RXTX group, > > >> > > > >> > I have just joined this group, and this is my first posting. > > >> > I wanted to pass on some information regarding rxtx, so apologies > if > > >> > this has been brought up before. I have searched back through the > > >> > archives but nothing specific came up. > > >> > > > >> > I am not a Java programmer, and I only came across rxtx a few days > ago. > > >> > > > >> > I use a piece of test equipment called a miniVNA > > >> > http://www.miniradiosolutions.com/ > > >> > > > >> > This is a serial USB controlled instrument, and it has control > software > > >> > available for MS windows, and a very old and now non-working Linux > > >> > application. > > >> > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > control the > > >> > miniVNA, obviously this application makes use of rxtx. > > >> > > > >> > The program worked fine on Windows, so I set about installing it > onto > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > running > > >> > fairly easily, sorting out the file locking by adding the uucp group > to > > >> > the users account as suggested (I used the 2.2pre binary files) I > then > > >> > passed the install instructions onto another miniVNA user, who also > uses > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > >> > also having file lock problems, but the uucp fix did not work. > Digging > > >> > into his system I found that there have been some changes in SUSE > 11.2. > > >> > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > >> > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > >> > checked, so: > > >> > > > >> > SUSE 11.1, var/lock is root:uucp > > >> > SUSE 11.2 var/lock is root:root > > >> > > > >> > A search on Google brought up several comments regarding this, and > also > > >> > a bugzilla entry. > > >> > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > >> > > > >> > However from reading the various posts, some of which are in the > bugzilla > > >> > entry, it appears that many distros may be, or have changed to this > > >> > configuration, and this will undoubtedly break several things, rxtx > > >> > included. > > >> > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > with the > > >> > no lock file option during configure, and that solved his problem. > > >> > > > >> > As this issue will probably take some time to get resolved across > all the > > >> > various Linux distros, it might be worth considering changing the > default > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > >> > versions of the lib in the binary archive. > > >> > > > >> > Thanks for your indulgence > > >> > > > >> > Andy > > >> > > > >> > _______________________________________________ > > >> > Rxtx mailing list > > >> > Rxtx at qbang.org > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > >> > > > >> > > >> > > >> > > >> -- > > >> Atte: > > >> Daniel Dario Morales Salas > > >> Ingeniero Civil en Computaci?n e Inform?tica > > >> Tel?fono: 02 684 3417 > > >> Celular: 09 643 1802 > > >> Santiago, Chile > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at qbang.org > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > -- > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > WWW: http://www.sharms.org/blog > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Thu Feb 4 05:31:46 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 12:31:46 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: <20100204123146.6cffeb67@workstation.site> Thank's for the confirmation. Something odd is going on somewhere in SUSE 11.2. I'll have to build up a local SUSE11.2 system to see if I can nail down exactly what is going on. Something is blocking the lockfiles in var/lock. The net is nice, but it's a bit difficult trying to work out what is going on what the machine in question is in Germany and I'm in the UK :-) Andy On Wed, 3 Feb 2010 22:26:38 -0300 Daniel Morales Salas wrote: > Hello > > I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva > 2010 this is what i get: > > drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ > > and i don't have ANY problem with lock files and RXTX in my java software. > All i had to do was add this rule to udev: > > # serial > KERNEL=="tty*", GROUP="uucp", MODE="0666" > > and that was all. Of course my user (metalklesk) is part of uucp group. > I did not make /var/lock writable to all users. > > Greetings ! > > 2010/2/3 Andy Eskelson > > > Thanks Steve, > > > > changing the serial ports back the uucp is not a big problem. I have a > > udev rule that can be easily modified already. However I cannot see any > > way of dealing with the var/lock problem apart from making it writable to > > all. Any thoughts? > > > > Andy > > > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > > wrote: > > > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > > and is a result of unified udev rules. You can work around this by > > > making udev change the group back to uucp until something more > > > happens. > > > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > > > Thanks, > > > > > > Steve > > > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > > Thanks Daniel, > > > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > > this for other programs for some time. > > > > . > > > > I don't think that this is the same problem. as far as I can understand > > > > things, the lock files are written in var/lock. Previously var/lock and > > > > dev/tty-whatever were the same group. Now with var/lock owned by and > > with > > > > a group of root:root anything other than root cannot create a lock > > > > file. Even minicom is broken by this change. > > > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > > Daniel Morales Salas wrote: > > > > > > > >> Hi > > > >> > > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > > the uucp > > > >> group did not work as it used to be in earlier versions of linux > > distros, > > > >> causing RXTX to not work as non root user. > > > >> > > > >> The problem appears because the existense of UDEV, now you MUST add a > > RULE > > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > > the > > > >> Serial Port. > > > >> > > > >> To solve the problem, without needing to recompile RXTX, you must add > > a rule > > > >> to grant permissions (0666) to the group for the device or port (tty*, > > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > > i > > > >> come back home i will give it to you (i am at work now). > > > >> > > > >> Greetings ! > > > >> > > > >> 2010/2/3 > > > >> > > > >> > Hello RXTX group, > > > >> > > > > >> > I have just joined this group, and this is my first posting. > > > >> > I wanted to pass on some information regarding rxtx, so apologies > > if > > > >> > this has been brought up before. I have searched back through the > > > >> > archives but nothing specific came up. > > > >> > > > > >> > I am not a Java programmer, and I only came across rxtx a few days > > ago. > > > >> > > > > >> > I use a piece of test equipment called a miniVNA > > > >> > http://www.miniradiosolutions.com/ > > > >> > > > > >> > This is a serial USB controlled instrument, and it has control > > software > > > >> > available for MS windows, and a very old and now non-working Linux > > > >> > application. > > > >> > > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > > control the > > > >> > miniVNA, obviously this application makes use of rxtx. > > > >> > > > > >> > The program worked fine on Windows, so I set about installing it > > onto > > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > > running > > > >> > fairly easily, sorting out the file locking by adding the uucp group > > to > > > >> > the users account as suggested (I used the 2.2pre binary files) I > > then > > > >> > passed the install instructions onto another miniVNA user, who also > > uses > > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > > >> > also having file lock problems, but the uucp fix did not work. > > Digging > > > >> > into his system I found that there have been some changes in SUSE > > 11.2. > > > >> > > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > > >> > > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > > >> > checked, so: > > > >> > > > > >> > SUSE 11.1, var/lock is root:uucp > > > >> > SUSE 11.2 var/lock is root:root > > > >> > > > > >> > A search on Google brought up several comments regarding this, and > > also > > > >> > a bugzilla entry. > > > >> > > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > >> > > > > >> > However from reading the various posts, some of which are in the > > bugzilla > > > >> > entry, it appears that many distros may be, or have changed to this > > > >> > configuration, and this will undoubtedly break several things, rxtx > > > >> > included. > > > >> > > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > > with the > > > >> > no lock file option during configure, and that solved his problem. > > > >> > > > > >> > As this issue will probably take some time to get resolved across > > all the > > > >> > various Linux distros, it might be worth considering changing the > > default > > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > > >> > versions of the lib in the binary archive. > > > >> > > > > >> > Thanks for your indulgence > > > >> > > > > >> > Andy > > > >> > > > > >> > _______________________________________________ > > > >> > Rxtx mailing list > > > >> > Rxtx at qbang.org > > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > > >> > > > > >> > > > >> > > > >> > > > >> -- > > > >> Atte: > > > >> Daniel Dario Morales Salas > > > >> Ingeniero Civil en Computaci?n e Inform?tica > > > >> Tel?fono: 02 684 3417 > > > >> Celular: 09 643 1802 > > > >> Santiago, Chile > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at qbang.org > > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > > > -- > > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > > > WWW: http://www.sharms.org/blog > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From Bob_Jacobsen at lbl.gov Thu Feb 4 09:26:49 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Thu, 4 Feb 2010 08:26:49 -0800 Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 Message-ID: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're using RXTX-2.2pre2, although it emits the known message about "Version mismatch". WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 After the usual messing around, we've got it working on 11 Windows versions, multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ have things working rarely say so, so I don't know whether anybody has gotten it to work on 10.4 or not. The problem encountered is this: dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib dyld: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib followed by the JVM crashing hard. I've got those dump files if that would help. Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If so, is there a patch I can get and build? Thanks Bob -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From tjarvi at qbang.org Thu Feb 4 14:22:21 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 4 Feb 2010 14:22:21 -0700 (MST) Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 In-Reply-To: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> References: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> Message-ID: On Thu, 4 Feb 2010, Bob Jacobsen wrote: > We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're > using RXTX-2.2pre2, although it emits the known message about "Version > mismatch". > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > > After the usual messing around, we've got it working on 11 Windows versions, > multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with > a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ > have things working rarely say so, so I don't know whether anybody has gotten > it to work on 10.4 or not. > > The problem encountered is this: > > dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > dyld: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > followed by the JVM crashing hard. I've got those dump files if that would > help. > > Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If > so, is there a patch I can get and build? > Hi Bob, I talked to a coworker about the problem you ran into. It appears that it is possible to target 'older' Mac systems through makefile configuration changes. "Configuring a Makefile-Based Project If you have a makefile-based project, you can also take advantage of SDK-based development, by adding the appropriate options to your compile and link commands. Using SDKs in makefile-based projects requires GCC 4.0 or later. To choose an SDK, you use the -isysroot option with the compiler and the -syslibroot option with the linker. Both options require that you specify the full path to the desired SDK directory. To set the Deployment OS version in a makefile, use a makefile variable of the form: ENVP= MACOSX_DEPLOYMENT_TARGET=10.4. To use this variable in your makefile, include it in front of your compile and link commands." http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html Or build on the oldest system you want to support. -- Trent Jarvi tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Thu Feb 4 14:56:19 2010 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Thu, 4 Feb 2010 14:56:19 -0700 Subject: [Rxtx] RXTX on 64 Bit Redhat In-Reply-To: References: <4ec9eab61001281448g3dd84910r867619948a4e0d7a@mail.gmail.com> Message-ID: Trent -- Finally fixed all my build related issues. I ran into another issue. On one of my machines my JDK is returning multiple folders for the "java.ext.dirs" (java.ext.dirs -> /opt/jdk1.6.0_17/jre/lib/ext:/usr/java/packages/lib/ext) system property. As a result my JVM wasn't able to detect the gnu.io.rxtx.properties. I am attaching a patch for RXTXCommDriver.java file to check for multiple locations. Also i have to assign permission 660 to all my dev ports to be located by RXTX. Pawan ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 5:12 PM To: Trent Jarvi Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Here is the error i get when i build the src from release-2-1-7 -bash-3.2$ make ( \ \ cd i686-pc-linux-gnu; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/ jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I/opt/jav a1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec - c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialImp.lo;\ if [ "Serial" = "Serial" ]; then \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I /opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_tim espec -c /home/jb_stg/rxtx/rxtx-devel/./src/fuserImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ else \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo; \ fi; \ ) gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/inclu de -I/opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need _timespec -c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -fPIC -DPIC -o /hom e/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/.libs/SerialImp.o /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:25:29: error: gnu_io_RXTXPort.h: No such file or directory In file included from /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:113: /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:91: error: expected specifier-qua lifier-list before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'jobject' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:408: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:409: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:410: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:411: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:415: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:416: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:417: error: expected '=', ',', '; ', 'asm' or '__attribute__' before 'is_interrupted' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:418: error: expected declaration specifiers or '...' before 'jint' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:424: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:441: error: expected ')' before ' *' token ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 4:57 PM To: Santosh Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Santosh -- Thank you. That fixed the issue. All -- What CVS branch or release should i use to get the latest RXTX src code. Pawan ________________________________ From: Santosh [mailto:santosh.ry at gmail.com] Sent: Thursday, January 28, 2010 3:49 PM To: Kharbanda, Pawan Cc: Trent Jarvi; rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat error "./configure: /bin/sh^M: bad interpreter: No such file or directory". I think you need to run dos2unix on script files before compiling. Thanks, Santosh On Thu, Jan 28, 2010 at 5:33 PM, Kharbanda, Pawan > wrote: Trent -- We are upgrading our exisiting OS and JDK on a project that rely heavily on RXTX api's. We are now using JDK1.6 32 bit (build 1.6.0_17-b04) and RedHat 5 on a 64 bit machine. Linux tocrhstg02.dot.state.co.us 2.6.18-164.6.1.el5 #1 SMP Tue Oct 27 11:30:06 EDT 2009 i686 i686 i386 GNU/Linux Red Hat Enterprise Linux Server release 5.4 (Tikanga) I tried to run version 2.1.7 r2 on it but not able to see any of my Digi ports I was able to access only /dev/ttyS0 (physical ports). Not sure if the problem is with the Digi driver or RXTX. I tried to open a Digi port with minicom and it worked fine. I also tried to get latest from CVS (rxtx-devel) and when I do "configure" I see this error "./configure: /bin/sh^M: bad interpreter: No such file or directory". Can someone please help me with this? Thanks for the help. Pawan _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch.txt URL: From juan.vicente.l.g at gmail.com Sat Feb 13 04:44:17 2010 From: juan.vicente.l.g at gmail.com (Juan Vicente Lopez Gutierrez) Date: Sat, 13 Feb 2010 12:44:17 +0100 Subject: [Rxtx] RXTX in macmini OSX 10.5 Message-ID: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> Hello. My name is Juanvi and I'm from Spain. I tried to launch a software created by me in the library CXR java to send information through the serial port and I can not make it work. In windows if I've done but not mac. I have a mac mini with OSX 10.5 and have read in the list of web mail that you CXR if you have managed to make it work on that operating system. I need you help me please. Do I make the mistake that shows me java: run: Stable Library =============================== Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 gnu.io.PortInUseException: Unknow Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:26) at TwoWatSerialComm.main(TwoWaySerialComm.java:106) Experimental: JNI_OnLoad called. GENERACION CORRECTA (total time: 0 seconds) I do not have permission to access the serial port, do not know. Os agradeceria much to sit down. A greeting and thanks. Pardon my English. Juanvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From juan.vicente.l.g at gmail.com Sat Feb 13 14:39:41 2010 From: juan.vicente.l.g at gmail.com (Juan Vicente Lopez Gutierrez) Date: Sat, 13 Feb 2010 22:39:41 +0100 Subject: [Rxtx] Fwd: RXTX in macmini OSX 10.5 In-Reply-To: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> References: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> Message-ID: <29405e5c1002131339m2059d169sdc8549ed9706a1af@mail.gmail.com> ---------- Forwarded message ---------- From: Juan Vicente Lopez Gutierrez Date: 2010/2/13 Subject: RXTX in macmini OSX 10.5 To: rxtx at qbang.org Hello. My name is Juanvi and I'm from Spain. I tried to launch a software created by me in the library CXR java to send information through the serial port and I can not make it work. In windows if I've done but not mac. I have a mac mini with OSX 10.5 and have read in the list of web mail that you CXR if you have managed to make it work on that operating system. I need you help me please. Do I make the mistake that shows me java: run: Stable Library =============================== Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 gnu.io.PortInUseException: Unknow Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:26) at TwoWatSerialComm.main(TwoWaySerialComm.java:106) Experimental: JNI_OnLoad called. GENERACION CORRECTA (total time: 0 seconds) I do not have permission to access the serial port, do not know. Os agradeceria much to sit down. A greeting and thanks. Pardon my English. Juanvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 01:02:21 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 13:32:21 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> My serial port driver(apparently) does not support receive timeout.I registered an event listener for DATA_AVAILABLE. However, the control never seems to come out of the 'while' loop.Shouldn't the InputStream.read return a '-1' immediately if no data is available (this seems to be the default operation)? This was tried on a x86 Linux desktop using rxtx-2.1-7 I've added the snippet for clarity: /******************************************************************************************************************************************************************************/ mySerialPort.enableReceiveThreshold(2000);//Trying to set a time limit for read calls System.out.println(mySerialPort.isReceiveTimeoutEnabled()); // I get FALSE, so its not supported on hardware. mySerialPort.addEventListener(this); mySerialPort.notifyOnDataAvailable(true);//register a event with //my SerialEvent listener implementation: public void serialEvent(SerialPortEvent arg0) { int newData=0; switch(arg0.getEventType()){ case SerialPortEvent.DATA_AVAILABLE: while (newData != -1) { try { newData = is.read();//This should eventually return a -1 if no data is available within a timeout.PROBLEM!! System.out.println("Got a byte from port:"+newData); if (newData == -1) { break; } } catch (IOException ex) { System.err.println(ex); return; } } break; } return; } /******************************************************************************************************************************************************************************/ Thanks and regards, Ravi From michael.erskine at ketech.com Wed Feb 3 02:26:50 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 09:26:50 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From michael.erskine at ketech.com Wed Feb 3 05:03:30 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 12:03:30 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > Michael Erskine > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > > Your event handler should handle the event and return immediately so that its > controlling thread can handle other events. I recommend a single read in the > following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) > reads all available bytes up to the size of the buffer returning the number of > bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } After posting this I considered the glaring possibility of the rawbuf read buffer being too small to receive all the available bytes and perhaps skipping data: after all, I'm guessing that is why we see so many posts asking for help with blocking implementations of read event handlers looping on "while(bytes are available)". I've spent this morning writing an extensive multi-threaded unit test suite that includes tests with a tiny buffer compared to the amount of data available and found that no data was being skipped. I now want to know why! The SerialPortEvent.DATA_AVAILABLE event must be being fired again if there is more data available on the input stream. If that is the case then it should be heavily documented with good examples in the wiki to avoid the types of developer anguish we see so regularly. BTW: I'm not at liberty to post the JUnit tests as they use my company's unit test suite framework. Regards, Michael Erskine. From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 06:18:04 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 18:48:04 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Hello Michael, I tried out your suggestion but the problem is that the read(rawbuf) blocks until the entire length of the rawbuf array has been read (blocking). I cannot decide on a reasonable size of the array because it varies from 2 bytes to as much as 50 byes (i'm communicating with a modem,each response is of a different length), which is why i wanted to use non blocking calls. But on a side note, read(byte[]) in turn calls the read() in a loop.In the native C function, the read is supposed to return a -1 upon timeout.But my driver does not support timeout.The default timeout value is zero and the linux select call upon zero time out causes an infinite wait.What am i missing...... Thanks and regards, Ravi Date: Wed, 3 Feb 2010 09:26:50 +0000 From: Michael Erskine To: "rxtx at qbang.org" Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: Content-Type: text/plain; charset="us-ascii" > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From m.kirkland at comcast.net Wed Feb 3 06:46:03 2010 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 3 Feb 2010 05:46:03 -0800 Subject: [Rxtx] One port blocking another port In-Reply-To: References: Message-ID: <68768633814F4D7D86761D34F0764FE0@bengal.net> It turns out this is caused by having the RTS/CTS flow control turned on and me not providing a true on the RTS pin. Somehow it seems the port timing out on a read allows the write to proceed. This is not an issue for my application but I wonder if the write should not proceed until the RTS pin is true even if a read times out. mk -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Monday, January 25, 2010 7:48 PM To: Mike Kirkland Cc: rxtx at qbang.org Subject: Re: [Rxtx] One port blocking another port On Mon, 25 Jan 2010, Mike Kirkland wrote: > > Hi All, > > ? > > I have a program that reads from one com port and writes to another com > port. It also does the same thing in reverse (reads from the second com port > and writes to the first one. It basically ties two com ports together. > > ? > > One port is very chatty and has a consent stream of data. The other port has > very little data. > > ? > > Both ports use a 5000 ms (5 second) time out. > > ? > > The issue I am having is that is appears that the first port?s write to the > second port is blocked while the second port is waiting for input. The first > port?s write proceeds only after the second port has timed out. > > ? > > I suppose I could have something twisted around in my code but I was > wondering if this is a know issue? > Hi Kirk, I've not seen a report like this. Perhaps some simple reproduction code will reveal a problem on your end or help us identify a problem in rxtx. I think there are several users doing multiport communication. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Wed Feb 3 07:03:58 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:03:58 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Message-ID: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> 2010/2/3 Ravishankar N > Hello Michael, > [..] > But on a side note, read(byte[]) in turn calls the read() in a loop.In the > native C function, the read is supposed to return a -1 upon timeout.But my > driver > does not support timeout.The default timeout value is zero and the linux > select call upon zero time out causes an infinite wait.What am i > missing...... > > When I have tested RXTX between platforms, I have observed "hangup" inside JNI driver when no data in Linux, is normal thing. Solution was setting the timeout for RXTX when no data from JNI driver. Something like that: commPort.enableReceiveTimeout(10); And it works perfect.... The only difference is that I am NOT using events - I am using continous read in separate thread and if data is available, is parsed and transferred to application using exception. Regards Mariusz > Thanks and regards, > Ravi > > Date: Wed, 3 Feb 2010 09:26:50 +0000 > From: Michael Erskine > To: "rxtx at qbang.org" > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > Message-ID: > > > Content-Type: text/plain; charset="us-ascii" > > > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of > > Ravishankar N > > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > > > My serial port driver(apparently) does not support receive timeout.I > > registered an event listener for DATA_AVAILABLE. However, the control > never > > seems to come out of the 'while' loop.Shouldn't the > > InputStream.read return a '-1' immediately if no data is available (this > seems > > to be the default operation)? > > Your event handler should handle the event and return immediately so that > its controlling thread can handle other events. I recommend a single read in > the following manner: rawbuf is a byte[] of "reasonable" size and the > read(byte[]) reads all available bytes up to the size of the buffer > returning the number of bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } > > This style of reading has worked for me with RXTX on Linux and Windows XP > for a good few years now in railway industry communications systems. Any > timeouts (largely unnecessary in my applications) can be handled elsewhere, > usually at a higher layer. > > Regards, > Michael Erskine. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Feb 3 07:22:55 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 3 Feb 2010 09:22:55 -0500 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: I'm guessing that this is driver specific. I recently had to support a select()/poll() infrastructure for a linux serial DD, its certainly non trivial to support async IO, so I suspect the problem in this case has to do with missing poll infrastructure in the device driver. This also has to coupled with special open flags for the device (which is within the rxtx code) The key routines within a 2.6 kernel linux device driver are shown below (if you have access to it for your particular device) are indicated below (here is a snippet from my device driver c code that supports polling/select). User space code to test this shown below also, note that the device needs to be opened with the O_NONBLOCK option to support the select/poll api // device driver code ..... /* * File operations supported by this driver. */ static struct file_operations iop_fops = { .owner = THIS_MODULE, .check_flags= iop_check_flags, .ioctl = iop_ioctl, .open = iop_open, .poll = iop_poll, // SUPPORT FOR SELECT/POLL infrastructure .read = iop_read, .release = iop_release, .write = iop_write, }; /** * Select/poll/epoll infrastructure. * * @param file * @param wait * * @return */ static unsigned int iop_poll(struct file *filp, poll_table *wait) { struct iop_device *devp = (struct iop_device *)filp->private_data; // the poll_table wait arg is an opaque pointer poll_wait(filp, &devp->readq, wait); // return from poll indicating whether we have read/write data unsigned int mask = 0; if (kfifo_len(devp->rx_fifo)) { mask |= (POLLIN | POLLRDNORM); } // @JC We don't do select on write yet // if (kfifo_len(devp->tx_fifo)) { // mask |= (POLLOUT | POLLWRNORM); // } // Only print out while debugging // if (mask != 0) { // printk (KERN_INFO "%s: [%04x]\n", __FUNCTION__, mask); // } return mask; } /** * device driver blocking and non blocking read function. This * function reads the requested number of bytes from the read * kfifo blocking as required. * * @param filp * @param buf * @param count * @param f_pos * * @return */ static ssize_t iop_read(struct file *filp, char __user *buf, size_t count, loff_t * ppos) { // access appropriate device struct struct iop_device *devp = (struct iop_device *) filp->private_data; ssize_t retval; // support non blocking mode (default) by checking if the kfifo is empty first if ((kfifo_len(devp->rx_fifo)==0) && (filp->f_flags & O_NONBLOCK)) { return -EAGAIN; } // wait for rx_fifo to receive data via receive interrupts retval = wait_event_interruptible(devp->readq, kfifo_len(devp->rx_fifo) != 0); // check for some error condition if (retval) { printk (KERN_ERR "%s: wait_event_interruptible returned[%d]\n", __FUNCTION__, retval); return retval; } // copy max requested bytes from rx_fifo to device buffer // this may still leave bytes in the kfifo for a subsequent read // if we are reading in a loop retval = kfifo_get(devp->rx_fifo, devp->rxbuf, count); // printk (KERN_INFO "%s: [%d] byte(s)\n", __FUNCTION__, retval); if (copy_to_user(buf, devp->rxbuf, retval)) { printk (KERN_ERR "%s: problem copying rx_fifo data to user buffer\n", __FUNCTION__); return -EFAULT; } return retval; } // a selection of my user space code reading via select()/poll()..... // user space open code iop_fd = ::open( deviceName.data(), O_RDWR | O_NONBLOCK); while ((bytes_to_expect - bytes_read) > 0) { // must reinitialize these between select calls fd_set readfds; FD_ZERO( &readfds ); FD_SET( iop_fd, &readfds ); // 1s sec read polling timeout struct timeval timeout; timeout.tv_sec = 1; timeout.tv_usec = 0; int rc = select( FD_SETSIZE, &readfds, NULL, NULL, &timeout ); // read from file when descriptor // indicates data available without blocking if ((rc > 0) && FD_ISSET(iop_fd, &readfds)) { // read into the appropriate offset within the rx_buf int temp = read(iop_fd, rx_buf + bytes_read, bytes_to_expect - bytes_read); if (!temp) { printf("EOF detected with %d bytes expected\n", bytes_to_expect - bytes_read); } else { bytes_read += temp; } } else if (rc < 0){ printf("%s: select on [%s], bytes_read[%d], errno=%d\n", __FUNCTION__, thread_args->device, bytes_read, errno); } else { printf("%s: select on [%s], bytes_read[%d], timeout\n", __FUNCTION__, thread_args->device, bytes_read); } } On Wed, Feb 3, 2010 at 9:03 AM, Mariusz Dec wrote: > > > 2010/2/3 Ravishankar N > >> Hello Michael, >> [..] >> >> But on a side note, read(byte[]) in turn calls the read() in a loop.In the >> native C function, the read is supposed to return a -1 upon timeout.But my >> driver >> does not support timeout.The default timeout value is zero and the linux >> select call upon zero time out causes an infinite wait.What am i >> missing...... >> >> > When I have tested RXTX between platforms, I have observed "hangup" inside > JNI driver when no data in Linux, is normal thing. > > Solution was setting the timeout for RXTX when no data from JNI driver. > > Something like that: > > commPort.enableReceiveTimeout(10); > > And it works perfect.... > > The only difference is that I am NOT using events - I am using continous > read in separate thread and if data is available, is parsed and transferred > to application using exception. > > Regards > Mariusz > > > >> Thanks and regards, >> Ravi >> >> Date: Wed, 3 Feb 2010 09:26:50 +0000 >> From: Michael Erskine >> To: "rxtx at qbang.org" >> Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? >> Message-ID: >> >> >> Content-Type: text/plain; charset="us-ascii" >> >> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >> Of >> > Ravishankar N >> > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? >> > >> > My serial port driver(apparently) does not support receive timeout.I >> > registered an event listener for DATA_AVAILABLE. However, the control >> never >> > seems to come out of the 'while' loop.Shouldn't the >> > InputStream.read return a '-1' immediately if no data is available (this >> seems >> > to be the default operation)? >> >> Your event handler should handle the event and return immediately so that >> its controlling thread can handle other events. I recommend a single read in >> the following manner: rawbuf is a byte[] of "reasonable" size and the >> read(byte[]) reads all available bytes up to the size of the buffer >> returning the number of bytes actually read... >> >> case SerialPortEvent.DATA_AVAILABLE: >> try { >> int i = is.read(rawbuf); >> if (i == -1) { >> << process EOF condition - should never happen >> >> return; >> } >> << process bytes (rawbuf, i); >> >> return; >> } catch (IOException e) { >> << promptly deal with exception >> >> return; >> } >> >> This style of reading has worked for me with RXTX on Linux and Windows XP >> for a good few years now in railway industry communications systems. Any >> timeouts (largely unnecessary in my applications) can be handled elsewhere, >> usually at a higher layer. >> >> Regards, >> Michael Erskine. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Feb 3 07:33:27 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:33:27 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: <73a89f361002030633j682610afia48dc7accd8e049b@mail.gmail.com> 2010/2/3 John Coffey > I'm guessing that this is driver specific. I recently had to support a > select()/poll() infrastructure for a linux serial DD, its certainly non > trivial to support async IO, so I suspect the problem in this case has to do > with missing poll infrastructure in the device driver. This also has to > coupled with special open flags for the device (which is within the rxtx > code) > > Yes, you are right, it may be driver specific, but in my case I haven't changed blocking JNI driver. I have added ONLY one call to RXTX method mentioned in my previous post and blocking (as seen as from Java app) gone out... Maybe this is not elegant, but works without problem in my app. I am using only FTDI chips and their drivers from couple of years and maybe this is the kind of the way to have no many problems with serial as well? Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From andyrxtx at g0poy.co.uk Wed Feb 3 11:09:04 2010 From: andyrxtx at g0poy.co.uk (andyrxtx at g0poy.co.uk) Date: Wed, 3 Feb 2010 18:09:04 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes Message-ID: <20100203180904.164f24dd@workstation.site> ?Hello RXTX group, I have just joined this group, and this is my first posting. I wanted to pass on some information regarding rxtx, so apologies if this has been brought up before. I have searched back through the archives but nothing specific came up. I am not a Java programmer, and I only came across rxtx a few days ago. I use a piece of test equipment called a miniVNA http://www.miniradiosolutions.com/ This is a serial USB controlled instrument, and it has control software available for MS windows, and a very old and now non-working Linux application. A few days ago Dietmar, DL2SBA released a Java application to control the miniVNA, obviously this application makes use of rxtx. The program worked fine on Windows, so I set about installing it onto Linux. I use SUSE11.1 After a few false starts, I got the system running fairly easily, sorting out the file locking by adding the uucp group to the users account as suggested (I used the 2.2pre binary files) I then passed the install instructions onto another miniVNA user, who also uses SUSE, but he ran into problems. To cut a long story short, he was also having file lock problems, but the uucp fix did not work. Digging into his system I found that there have been some changes in SUSE 11.2. tty ports are now assigned to the dialout group rather than uucp. A hint in the rxtx INSTALL file, suggested that var/lock needs to be checked, so: SUSE 11.1, var/lock is root:uucp SUSE 11.2 var/lock is root:root A search on Google brought up several comments regarding this, and also a bugzilla entry. https://bugzilla.novell.com/show_bug.cgi?id=552095 However from reading the various posts, some of which are in the bugzilla entry, it appears that many distros may be, or have changed to this configuration, and this will undoubtedly break several things, rxtx included. I solved my fellow SUSE users problem by compiling the rxtx libs with the no lock file option during configure, and that solved his problem. As this issue will probably take some time to get resolved across all the various Linux distros, it might be worth considering changing the default on the Linux build of rxtx not to use lockfiles, or provide the two versions of the lib in the binary archive. Thanks for your indulgence Andy From damorales at gmail.com Wed Feb 3 11:33:23 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 15:33:23 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203180904.164f24dd@workstation.site> References: <20100203180904.164f24dd@workstation.site> Message-ID: Hi I had the same problem in Mandriva 2010 and yes, adding the user to the uucp group did not work as it used to be in earlier versions of linux distros, causing RXTX to not work as non root user. The problem appears because the existense of UDEV, now you MUST add a RULE so the group (uucp or whatever) have access (Read, Write, Execute) to the Serial Port. To solve the problem, without needing to recompile RXTX, you must add a rule to grant permissions (0666) to the group for the device or port (tty*, ttyUSB*, etc). I do not remember now what is the line i added but when i come back home i will give it to you (i am at work now). Greetings ! 2010/2/3 > Hello RXTX group, > > I have just joined this group, and this is my first posting. > I wanted to pass on some information regarding rxtx, so apologies if > this has been brought up before. I have searched back through the > archives but nothing specific came up. > > I am not a Java programmer, and I only came across rxtx a few days ago. > > I use a piece of test equipment called a miniVNA > http://www.miniradiosolutions.com/ > > This is a serial USB controlled instrument, and it has control software > available for MS windows, and a very old and now non-working Linux > application. > > A few days ago Dietmar, DL2SBA released a Java application to control the > miniVNA, obviously this application makes use of rxtx. > > The program worked fine on Windows, so I set about installing it onto > Linux. I use SUSE11.1 After a few false starts, I got the system running > fairly easily, sorting out the file locking by adding the uucp group to > the users account as suggested (I used the 2.2pre binary files) I then > passed the install instructions onto another miniVNA user, who also uses > SUSE, but he ran into problems. To cut a long story short, he was > also having file lock problems, but the uucp fix did not work. Digging > into his system I found that there have been some changes in SUSE 11.2. > > tty ports are now assigned to the dialout group rather than uucp. > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > checked, so: > > SUSE 11.1, var/lock is root:uucp > SUSE 11.2 var/lock is root:root > > A search on Google brought up several comments regarding this, and also > a bugzilla entry. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > However from reading the various posts, some of which are in the bugzilla > entry, it appears that many distros may be, or have changed to this > configuration, and this will undoubtedly break several things, rxtx > included. > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > no lock file option during configure, and that solved his problem. > > As this issue will probably take some time to get resolved across all the > various Linux distros, it might be worth considering changing the default > on the Linux build of rxtx not to use lockfiles, or provide the two > versions of the lib in the binary archive. > > Thanks for your indulgence > > Andy > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Wed Feb 3 12:07:02 2010 From: andy at g0poy.com (Andy Eskelson) Date: Wed, 3 Feb 2010 19:07:02 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> Message-ID: <20100203190702.1b0e7015@workstation.site> Thanks Daniel, I am aware of the permissions problem, I have had a udev rules to solve this for other programs for some time. . I don't think that this is the same problem. as far as I can understand things, the lock files are written in var/lock. Previously var/lock and dev/tty-whatever were the same group. Now with var/lock owned by and with a group of root:root anything other than root cannot create a lock file. Even minicom is broken by this change. This change is going to have quite a few knock-on effects I think. Andy On Wed, 3 Feb 2010 15:33:23 -0300 Daniel Morales Salas wrote: > Hi > > I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > group did not work as it used to be in earlier versions of linux distros, > causing RXTX to not work as non root user. > > The problem appears because the existense of UDEV, now you MUST add a RULE > so the group (uucp or whatever) have access (Read, Write, Execute) to the > Serial Port. > > To solve the problem, without needing to recompile RXTX, you must add a rule > to grant permissions (0666) to the group for the device or port (tty*, > ttyUSB*, etc). I do not remember now what is the line i added but when i > come back home i will give it to you (i am at work now). > > Greetings ! > > 2010/2/3 > > > Hello RXTX group, > > > > I have just joined this group, and this is my first posting. > > I wanted to pass on some information regarding rxtx, so apologies if > > this has been brought up before. I have searched back through the > > archives but nothing specific came up. > > > > I am not a Java programmer, and I only came across rxtx a few days ago. > > > > I use a piece of test equipment called a miniVNA > > http://www.miniradiosolutions.com/ > > > > This is a serial USB controlled instrument, and it has control software > > available for MS windows, and a very old and now non-working Linux > > application. > > > > A few days ago Dietmar, DL2SBA released a Java application to control the > > miniVNA, obviously this application makes use of rxtx. > > > > The program worked fine on Windows, so I set about installing it onto > > Linux. I use SUSE11.1 After a few false starts, I got the system running > > fairly easily, sorting out the file locking by adding the uucp group to > > the users account as suggested (I used the 2.2pre binary files) I then > > passed the install instructions onto another miniVNA user, who also uses > > SUSE, but he ran into problems. To cut a long story short, he was > > also having file lock problems, but the uucp fix did not work. Digging > > into his system I found that there have been some changes in SUSE 11.2. > > > > tty ports are now assigned to the dialout group rather than uucp. > > > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > checked, so: > > > > SUSE 11.1, var/lock is root:uucp > > SUSE 11.2 var/lock is root:root > > > > A search on Google brought up several comments regarding this, and also > > a bugzilla entry. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > However from reading the various posts, some of which are in the bugzilla > > entry, it appears that many distros may be, or have changed to this > > configuration, and this will undoubtedly break several things, rxtx > > included. > > > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > > no lock file option during configure, and that solved his problem. > > > > As this issue will probably take some time to get resolved across all the > > various Linux distros, it might be worth considering changing the default > > on the Linux build of rxtx not to use lockfiles, or provide the two > > versions of the lib in the binary archive. > > > > Thanks for your indulgence > > > > Andy > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From thisdyingdream at gmail.com Wed Feb 3 12:32:35 2010 From: thisdyingdream at gmail.com (Steven Harms) Date: Wed, 3 Feb 2010 14:32:35 -0500 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203190702.1b0e7015@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: This is currently a bug in OpenSUSE that affects more than just rxtx, and is a result of unified udev rules. You can work around this by making udev change the group back to uucp until something more happens. https://bugzilla.novell.com/show_bug.cgi?id=552095 Thanks, Steve On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > Thanks Daniel, > > I am aware of the permissions problem, I have had a udev rules to solve > this for other programs for some time. > . > I don't think that this is the same problem. as far as I can understand > things, the lock files are written in var/lock. Previously var/lock and > dev/tty-whatever were the same group. Now with var/lock owned by and with > a group of root:root anything other than root cannot create a lock > file. Even minicom is broken by this change. > > This change is going to have quite a few knock-on effects I think. > > > Andy > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > Daniel Morales Salas wrote: > >> Hi >> >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp >> group did not work as it used to be in earlier versions of linux distros, >> causing RXTX to not work as non root user. >> >> The problem appears because the existense of UDEV, now you MUST add a RULE >> so the group (uucp or whatever) have access (Read, Write, Execute) to the >> Serial Port. >> >> To solve the problem, without needing to recompile RXTX, you must add a rule >> to grant permissions (0666) to the group for the device or port (tty*, >> ttyUSB*, etc). I do not remember now what is the line i added but when i >> come back home i will give it to you (i am at work now). >> >> Greetings ! >> >> 2010/2/3 >> >> > Hello RXTX group, >> > >> > I have just joined this group, and this is my first posting. >> > I wanted to pass on ?some information regarding rxtx, so apologies if >> > this has been brought up before. I have searched back through the >> > archives but nothing specific came up. >> > >> > I am not a Java programmer, and I only came across rxtx a few days ago. >> > >> > I use a piece of test equipment called a miniVNA >> > http://www.miniradiosolutions.com/ >> > >> > This is a serial USB controlled instrument, and it has control software >> > available for MS windows, and a very old and now non-working Linux >> > application. >> > >> > A few days ago Dietmar, DL2SBA released a Java application to control the >> > miniVNA, obviously this application makes use of rxtx. >> > >> > The program worked fine on Windows, so I set about installing it onto >> > Linux. I use SUSE11.1 After a few false starts, I got the system running >> > fairly easily, sorting out the file locking by adding the uucp group to >> > the users account as suggested (I used the 2.2pre binary files) I then >> > passed the install instructions onto another miniVNA user, who also uses >> > SUSE, but he ran into problems. To cut a long story short, he was >> > also having file lock problems, but the uucp fix did not work. Digging >> > into his system I found that there have been some changes in SUSE 11.2. >> > >> > tty ports are now assigned to the dialout group rather than uucp. >> > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be >> > checked, so: >> > >> > SUSE 11.1, var/lock is root:uucp >> > SUSE 11.2 var/lock is root:root >> > >> > A search on Google brought up several comments regarding this, and also >> > a ?bugzilla entry. >> > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 >> > >> > However from reading the various posts, some of which are in the bugzilla >> > entry, it appears that many distros may be, or have changed to this >> > configuration, and this will undoubtedly break several things, rxtx >> > included. >> > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the >> > no lock file option during configure, and that solved his problem. >> > >> > As this issue will probably take some time to get resolved across all the >> > various Linux distros, it might be worth considering changing the default >> > on the Linux build of rxtx not to use lockfiles, or provide the two >> > versions of the lib in the binary archive. >> > >> > Thanks for your indulgence >> > >> > Andy >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> >> >> >> -- >> Atte: >> Daniel Dario Morales Salas >> Ingeniero Civil en Computaci?n e Inform?tica >> Tel?fono: 02 684 3417 >> Celular: 09 643 1802 >> Santiago, Chile > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 WWW: http://www.sharms.org/blog From andy at g0poy.com Wed Feb 3 17:58:29 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 00:58:29 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: <20100204005829.7dc944e1@workstation.site> Thanks Steve, changing the serial ports back the uucp is not a big problem. I have a udev rule that can be easily modified already. However I cannot see any way of dealing with the var/lock problem apart from making it writable to all. Any thoughts? Andy On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms wrote: > This is currently a bug in OpenSUSE that affects more than just rxtx, > and is a result of unified udev rules. You can work around this by > making udev change the group back to uucp until something more > happens. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > Thanks, > > Steve > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > Thanks Daniel, > > > > I am aware of the permissions problem, I have had a udev rules to solve > > this for other programs for some time. > > . > > I don't think that this is the same problem. as far as I can understand > > things, the lock files are written in var/lock. Previously var/lock and > > dev/tty-whatever were the same group. Now with var/lock owned by and with > > a group of root:root anything other than root cannot create a lock > > file. Even minicom is broken by this change. > > > > This change is going to have quite a few knock-on effects I think. > > > > > > Andy > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > Daniel Morales Salas wrote: > > > >> Hi > >> > >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > >> group did not work as it used to be in earlier versions of linux distros, > >> causing RXTX to not work as non root user. > >> > >> The problem appears because the existense of UDEV, now you MUST add a RULE > >> so the group (uucp or whatever) have access (Read, Write, Execute) to the > >> Serial Port. > >> > >> To solve the problem, without needing to recompile RXTX, you must add a rule > >> to grant permissions (0666) to the group for the device or port (tty*, > >> ttyUSB*, etc). I do not remember now what is the line i added but when i > >> come back home i will give it to you (i am at work now). > >> > >> Greetings ! > >> > >> 2010/2/3 > >> > >> > Hello RXTX group, > >> > > >> > I have just joined this group, and this is my first posting. > >> > I wanted to pass on ?some information regarding rxtx, so apologies if > >> > this has been brought up before. I have searched back through the > >> > archives but nothing specific came up. > >> > > >> > I am not a Java programmer, and I only came across rxtx a few days ago. > >> > > >> > I use a piece of test equipment called a miniVNA > >> > http://www.miniradiosolutions.com/ > >> > > >> > This is a serial USB controlled instrument, and it has control software > >> > available for MS windows, and a very old and now non-working Linux > >> > application. > >> > > >> > A few days ago Dietmar, DL2SBA released a Java application to control the > >> > miniVNA, obviously this application makes use of rxtx. > >> > > >> > The program worked fine on Windows, so I set about installing it onto > >> > Linux. I use SUSE11.1 After a few false starts, I got the system running > >> > fairly easily, sorting out the file locking by adding the uucp group to > >> > the users account as suggested (I used the 2.2pre binary files) I then > >> > passed the install instructions onto another miniVNA user, who also uses > >> > SUSE, but he ran into problems. To cut a long story short, he was > >> > also having file lock problems, but the uucp fix did not work. Digging > >> > into his system I found that there have been some changes in SUSE 11.2. > >> > > >> > tty ports are now assigned to the dialout group rather than uucp. > >> > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > >> > checked, so: > >> > > >> > SUSE 11.1, var/lock is root:uucp > >> > SUSE 11.2 var/lock is root:root > >> > > >> > A search on Google brought up several comments regarding this, and also > >> > a ?bugzilla entry. > >> > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > >> > > >> > However from reading the various posts, some of which are in the bugzilla > >> > entry, it appears that many distros may be, or have changed to this > >> > configuration, and this will undoubtedly break several things, rxtx > >> > included. > >> > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the > >> > no lock file option during configure, and that solved his problem. > >> > > >> > As this issue will probably take some time to get resolved across all the > >> > various Linux distros, it might be worth considering changing the default > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > >> > versions of the lib in the binary archive. > >> > > >> > Thanks for your indulgence > >> > > >> > Andy > >> > > >> > _______________________________________________ > >> > Rxtx mailing list > >> > Rxtx at qbang.org > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > >> > >> > >> > >> -- > >> Atte: > >> Daniel Dario Morales Salas > >> Ingeniero Civil en Computaci?n e Inform?tica > >> Tel?fono: 02 684 3417 > >> Celular: 09 643 1802 > >> Santiago, Chile > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > WWW: http://www.sharms.org/blog From damorales at gmail.com Wed Feb 3 18:26:38 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 22:26:38 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100204005829.7dc944e1@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: Hello I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva 2010 this is what i get: drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ and i don't have ANY problem with lock files and RXTX in my java software. All i had to do was add this rule to udev: # serial KERNEL=="tty*", GROUP="uucp", MODE="0666" and that was all. Of course my user (metalklesk) is part of uucp group. I did not make /var/lock writable to all users. Greetings ! 2010/2/3 Andy Eskelson > Thanks Steve, > > changing the serial ports back the uucp is not a big problem. I have a > udev rule that can be easily modified already. However I cannot see any > way of dealing with the var/lock problem apart from making it writable to > all. Any thoughts? > > Andy > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > wrote: > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > and is a result of unified udev rules. You can work around this by > > making udev change the group back to uucp until something more > > happens. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > Thanks, > > > > Steve > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > Thanks Daniel, > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > this for other programs for some time. > > > . > > > I don't think that this is the same problem. as far as I can understand > > > things, the lock files are written in var/lock. Previously var/lock and > > > dev/tty-whatever were the same group. Now with var/lock owned by and > with > > > a group of root:root anything other than root cannot create a lock > > > file. Even minicom is broken by this change. > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > Daniel Morales Salas wrote: > > > > > >> Hi > > >> > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > the uucp > > >> group did not work as it used to be in earlier versions of linux > distros, > > >> causing RXTX to not work as non root user. > > >> > > >> The problem appears because the existense of UDEV, now you MUST add a > RULE > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > the > > >> Serial Port. > > >> > > >> To solve the problem, without needing to recompile RXTX, you must add > a rule > > >> to grant permissions (0666) to the group for the device or port (tty*, > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > i > > >> come back home i will give it to you (i am at work now). > > >> > > >> Greetings ! > > >> > > >> 2010/2/3 > > >> > > >> > Hello RXTX group, > > >> > > > >> > I have just joined this group, and this is my first posting. > > >> > I wanted to pass on some information regarding rxtx, so apologies > if > > >> > this has been brought up before. I have searched back through the > > >> > archives but nothing specific came up. > > >> > > > >> > I am not a Java programmer, and I only came across rxtx a few days > ago. > > >> > > > >> > I use a piece of test equipment called a miniVNA > > >> > http://www.miniradiosolutions.com/ > > >> > > > >> > This is a serial USB controlled instrument, and it has control > software > > >> > available for MS windows, and a very old and now non-working Linux > > >> > application. > > >> > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > control the > > >> > miniVNA, obviously this application makes use of rxtx. > > >> > > > >> > The program worked fine on Windows, so I set about installing it > onto > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > running > > >> > fairly easily, sorting out the file locking by adding the uucp group > to > > >> > the users account as suggested (I used the 2.2pre binary files) I > then > > >> > passed the install instructions onto another miniVNA user, who also > uses > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > >> > also having file lock problems, but the uucp fix did not work. > Digging > > >> > into his system I found that there have been some changes in SUSE > 11.2. > > >> > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > >> > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > >> > checked, so: > > >> > > > >> > SUSE 11.1, var/lock is root:uucp > > >> > SUSE 11.2 var/lock is root:root > > >> > > > >> > A search on Google brought up several comments regarding this, and > also > > >> > a bugzilla entry. > > >> > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > >> > > > >> > However from reading the various posts, some of which are in the > bugzilla > > >> > entry, it appears that many distros may be, or have changed to this > > >> > configuration, and this will undoubtedly break several things, rxtx > > >> > included. > > >> > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > with the > > >> > no lock file option during configure, and that solved his problem. > > >> > > > >> > As this issue will probably take some time to get resolved across > all the > > >> > various Linux distros, it might be worth considering changing the > default > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > >> > versions of the lib in the binary archive. > > >> > > > >> > Thanks for your indulgence > > >> > > > >> > Andy > > >> > > > >> > _______________________________________________ > > >> > Rxtx mailing list > > >> > Rxtx at qbang.org > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > >> > > > >> > > >> > > >> > > >> -- > > >> Atte: > > >> Daniel Dario Morales Salas > > >> Ingeniero Civil en Computaci?n e Inform?tica > > >> Tel?fono: 02 684 3417 > > >> Celular: 09 643 1802 > > >> Santiago, Chile > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at qbang.org > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > -- > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > WWW: http://www.sharms.org/blog > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Thu Feb 4 05:31:46 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 12:31:46 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: <20100204123146.6cffeb67@workstation.site> Thank's for the confirmation. Something odd is going on somewhere in SUSE 11.2. I'll have to build up a local SUSE11.2 system to see if I can nail down exactly what is going on. Something is blocking the lockfiles in var/lock. The net is nice, but it's a bit difficult trying to work out what is going on what the machine in question is in Germany and I'm in the UK :-) Andy On Wed, 3 Feb 2010 22:26:38 -0300 Daniel Morales Salas wrote: > Hello > > I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva > 2010 this is what i get: > > drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ > > and i don't have ANY problem with lock files and RXTX in my java software. > All i had to do was add this rule to udev: > > # serial > KERNEL=="tty*", GROUP="uucp", MODE="0666" > > and that was all. Of course my user (metalklesk) is part of uucp group. > I did not make /var/lock writable to all users. > > Greetings ! > > 2010/2/3 Andy Eskelson > > > Thanks Steve, > > > > changing the serial ports back the uucp is not a big problem. I have a > > udev rule that can be easily modified already. However I cannot see any > > way of dealing with the var/lock problem apart from making it writable to > > all. Any thoughts? > > > > Andy > > > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > > wrote: > > > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > > and is a result of unified udev rules. You can work around this by > > > making udev change the group back to uucp until something more > > > happens. > > > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > > > Thanks, > > > > > > Steve > > > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > > Thanks Daniel, > > > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > > this for other programs for some time. > > > > . > > > > I don't think that this is the same problem. as far as I can understand > > > > things, the lock files are written in var/lock. Previously var/lock and > > > > dev/tty-whatever were the same group. Now with var/lock owned by and > > with > > > > a group of root:root anything other than root cannot create a lock > > > > file. Even minicom is broken by this change. > > > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > > Daniel Morales Salas wrote: > > > > > > > >> Hi > > > >> > > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > > the uucp > > > >> group did not work as it used to be in earlier versions of linux > > distros, > > > >> causing RXTX to not work as non root user. > > > >> > > > >> The problem appears because the existense of UDEV, now you MUST add a > > RULE > > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > > the > > > >> Serial Port. > > > >> > > > >> To solve the problem, without needing to recompile RXTX, you must add > > a rule > > > >> to grant permissions (0666) to the group for the device or port (tty*, > > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > > i > > > >> come back home i will give it to you (i am at work now). > > > >> > > > >> Greetings ! > > > >> > > > >> 2010/2/3 > > > >> > > > >> > Hello RXTX group, > > > >> > > > > >> > I have just joined this group, and this is my first posting. > > > >> > I wanted to pass on some information regarding rxtx, so apologies > > if > > > >> > this has been brought up before. I have searched back through the > > > >> > archives but nothing specific came up. > > > >> > > > > >> > I am not a Java programmer, and I only came across rxtx a few days > > ago. > > > >> > > > > >> > I use a piece of test equipment called a miniVNA > > > >> > http://www.miniradiosolutions.com/ > > > >> > > > > >> > This is a serial USB controlled instrument, and it has control > > software > > > >> > available for MS windows, and a very old and now non-working Linux > > > >> > application. > > > >> > > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > > control the > > > >> > miniVNA, obviously this application makes use of rxtx. > > > >> > > > > >> > The program worked fine on Windows, so I set about installing it > > onto > > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > > running > > > >> > fairly easily, sorting out the file locking by adding the uucp group > > to > > > >> > the users account as suggested (I used the 2.2pre binary files) I > > then > > > >> > passed the install instructions onto another miniVNA user, who also > > uses > > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > > >> > also having file lock problems, but the uucp fix did not work. > > Digging > > > >> > into his system I found that there have been some changes in SUSE > > 11.2. > > > >> > > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > > >> > > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > > >> > checked, so: > > > >> > > > > >> > SUSE 11.1, var/lock is root:uucp > > > >> > SUSE 11.2 var/lock is root:root > > > >> > > > > >> > A search on Google brought up several comments regarding this, and > > also > > > >> > a bugzilla entry. > > > >> > > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > >> > > > > >> > However from reading the various posts, some of which are in the > > bugzilla > > > >> > entry, it appears that many distros may be, or have changed to this > > > >> > configuration, and this will undoubtedly break several things, rxtx > > > >> > included. > > > >> > > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > > with the > > > >> > no lock file option during configure, and that solved his problem. > > > >> > > > > >> > As this issue will probably take some time to get resolved across > > all the > > > >> > various Linux distros, it might be worth considering changing the > > default > > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > > >> > versions of the lib in the binary archive. > > > >> > > > > >> > Thanks for your indulgence > > > >> > > > > >> > Andy > > > >> > > > > >> > _______________________________________________ > > > >> > Rxtx mailing list > > > >> > Rxtx at qbang.org > > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > > >> > > > > >> > > > >> > > > >> > > > >> -- > > > >> Atte: > > > >> Daniel Dario Morales Salas > > > >> Ingeniero Civil en Computaci?n e Inform?tica > > > >> Tel?fono: 02 684 3417 > > > >> Celular: 09 643 1802 > > > >> Santiago, Chile > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at qbang.org > > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > > > -- > > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > > > WWW: http://www.sharms.org/blog > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From Bob_Jacobsen at lbl.gov Thu Feb 4 09:26:49 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Thu, 4 Feb 2010 08:26:49 -0800 Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 Message-ID: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're using RXTX-2.2pre2, although it emits the known message about "Version mismatch". WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 After the usual messing around, we've got it working on 11 Windows versions, multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ have things working rarely say so, so I don't know whether anybody has gotten it to work on 10.4 or not. The problem encountered is this: dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib dyld: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib followed by the JVM crashing hard. I've got those dump files if that would help. Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If so, is there a patch I can get and build? Thanks Bob -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From tjarvi at qbang.org Thu Feb 4 14:22:21 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 4 Feb 2010 14:22:21 -0700 (MST) Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 In-Reply-To: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> References: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> Message-ID: On Thu, 4 Feb 2010, Bob Jacobsen wrote: > We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're > using RXTX-2.2pre2, although it emits the known message about "Version > mismatch". > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > > After the usual messing around, we've got it working on 11 Windows versions, > multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with > a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ > have things working rarely say so, so I don't know whether anybody has gotten > it to work on 10.4 or not. > > The problem encountered is this: > > dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > dyld: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > followed by the JVM crashing hard. I've got those dump files if that would > help. > > Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If > so, is there a patch I can get and build? > Hi Bob, I talked to a coworker about the problem you ran into. It appears that it is possible to target 'older' Mac systems through makefile configuration changes. "Configuring a Makefile-Based Project If you have a makefile-based project, you can also take advantage of SDK-based development, by adding the appropriate options to your compile and link commands. Using SDKs in makefile-based projects requires GCC 4.0 or later. To choose an SDK, you use the -isysroot option with the compiler and the -syslibroot option with the linker. Both options require that you specify the full path to the desired SDK directory. To set the Deployment OS version in a makefile, use a makefile variable of the form: ENVP= MACOSX_DEPLOYMENT_TARGET=10.4. To use this variable in your makefile, include it in front of your compile and link commands." http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html Or build on the oldest system you want to support. -- Trent Jarvi tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Thu Feb 4 14:56:19 2010 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Thu, 4 Feb 2010 14:56:19 -0700 Subject: [Rxtx] RXTX on 64 Bit Redhat In-Reply-To: References: <4ec9eab61001281448g3dd84910r867619948a4e0d7a@mail.gmail.com> Message-ID: Trent -- Finally fixed all my build related issues. I ran into another issue. On one of my machines my JDK is returning multiple folders for the "java.ext.dirs" (java.ext.dirs -> /opt/jdk1.6.0_17/jre/lib/ext:/usr/java/packages/lib/ext) system property. As a result my JVM wasn't able to detect the gnu.io.rxtx.properties. I am attaching a patch for RXTXCommDriver.java file to check for multiple locations. Also i have to assign permission 660 to all my dev ports to be located by RXTX. Pawan ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 5:12 PM To: Trent Jarvi Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Here is the error i get when i build the src from release-2-1-7 -bash-3.2$ make ( \ \ cd i686-pc-linux-gnu; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/ jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I/opt/jav a1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec - c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialImp.lo;\ if [ "Serial" = "Serial" ]; then \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I /opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_tim espec -c /home/jb_stg/rxtx/rxtx-devel/./src/fuserImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ else \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo; \ fi; \ ) gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/inclu de -I/opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need _timespec -c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -fPIC -DPIC -o /hom e/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/.libs/SerialImp.o /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:25:29: error: gnu_io_RXTXPort.h: No such file or directory In file included from /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:113: /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:91: error: expected specifier-qua lifier-list before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'jobject' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:408: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:409: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:410: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:411: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:415: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:416: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:417: error: expected '=', ',', '; ', 'asm' or '__attribute__' before 'is_interrupted' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:418: error: expected declaration specifiers or '...' before 'jint' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:424: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:441: error: expected ')' before ' *' token ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 4:57 PM To: Santosh Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Santosh -- Thank you. That fixed the issue. All -- What CVS branch or release should i use to get the latest RXTX src code. Pawan ________________________________ From: Santosh [mailto:santosh.ry at gmail.com] Sent: Thursday, January 28, 2010 3:49 PM To: Kharbanda, Pawan Cc: Trent Jarvi; rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat error "./configure: /bin/sh^M: bad interpreter: No such file or directory". I think you need to run dos2unix on script files before compiling. Thanks, Santosh On Thu, Jan 28, 2010 at 5:33 PM, Kharbanda, Pawan > wrote: Trent -- We are upgrading our exisiting OS and JDK on a project that rely heavily on RXTX api's. We are now using JDK1.6 32 bit (build 1.6.0_17-b04) and RedHat 5 on a 64 bit machine. Linux tocrhstg02.dot.state.co.us 2.6.18-164.6.1.el5 #1 SMP Tue Oct 27 11:30:06 EDT 2009 i686 i686 i386 GNU/Linux Red Hat Enterprise Linux Server release 5.4 (Tikanga) I tried to run version 2.1.7 r2 on it but not able to see any of my Digi ports I was able to access only /dev/ttyS0 (physical ports). Not sure if the problem is with the Digi driver or RXTX. I tried to open a Digi port with minicom and it worked fine. I also tried to get latest from CVS (rxtx-devel) and when I do "configure" I see this error "./configure: /bin/sh^M: bad interpreter: No such file or directory". Can someone please help me with this? Thanks for the help. Pawan _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch.txt URL: From juan.vicente.l.g at gmail.com Sat Feb 13 04:44:17 2010 From: juan.vicente.l.g at gmail.com (Juan Vicente Lopez Gutierrez) Date: Sat, 13 Feb 2010 12:44:17 +0100 Subject: [Rxtx] RXTX in macmini OSX 10.5 Message-ID: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> Hello. My name is Juanvi and I'm from Spain. I tried to launch a software created by me in the library CXR java to send information through the serial port and I can not make it work. In windows if I've done but not mac. I have a mac mini with OSX 10.5 and have read in the list of web mail that you CXR if you have managed to make it work on that operating system. I need you help me please. Do I make the mistake that shows me java: run: Stable Library =============================== Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 gnu.io.PortInUseException: Unknow Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:26) at TwoWatSerialComm.main(TwoWaySerialComm.java:106) Experimental: JNI_OnLoad called. GENERACION CORRECTA (total time: 0 seconds) I do not have permission to access the serial port, do not know. Os agradeceria much to sit down. A greeting and thanks. Pardon my English. Juanvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From juan.vicente.l.g at gmail.com Sat Feb 13 14:39:41 2010 From: juan.vicente.l.g at gmail.com (Juan Vicente Lopez Gutierrez) Date: Sat, 13 Feb 2010 22:39:41 +0100 Subject: [Rxtx] Fwd: RXTX in macmini OSX 10.5 In-Reply-To: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> References: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> Message-ID: <29405e5c1002131339m2059d169sdc8549ed9706a1af@mail.gmail.com> ---------- Forwarded message ---------- From: Juan Vicente Lopez Gutierrez Date: 2010/2/13 Subject: RXTX in macmini OSX 10.5 To: rxtx at qbang.org Hello. My name is Juanvi and I'm from Spain. I tried to launch a software created by me in the library CXR java to send information through the serial port and I can not make it work. In windows if I've done but not mac. I have a mac mini with OSX 10.5 and have read in the list of web mail that you CXR if you have managed to make it work on that operating system. I need you help me please. Do I make the mistake that shows me java: run: Stable Library =============================== Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 gnu.io.PortInUseException: Unknow Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:26) at TwoWatSerialComm.main(TwoWaySerialComm.java:106) Experimental: JNI_OnLoad called. GENERACION CORRECTA (total time: 0 seconds) I do not have permission to access the serial port, do not know. Os agradeceria much to sit down. A greeting and thanks. Pardon my English. Juanvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 01:02:21 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 13:32:21 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> My serial port driver(apparently) does not support receive timeout.I registered an event listener for DATA_AVAILABLE. However, the control never seems to come out of the 'while' loop.Shouldn't the InputStream.read return a '-1' immediately if no data is available (this seems to be the default operation)? This was tried on a x86 Linux desktop using rxtx-2.1-7 I've added the snippet for clarity: /******************************************************************************************************************************************************************************/ mySerialPort.enableReceiveThreshold(2000);//Trying to set a time limit for read calls System.out.println(mySerialPort.isReceiveTimeoutEnabled()); // I get FALSE, so its not supported on hardware. mySerialPort.addEventListener(this); mySerialPort.notifyOnDataAvailable(true);//register a event with //my SerialEvent listener implementation: public void serialEvent(SerialPortEvent arg0) { int newData=0; switch(arg0.getEventType()){ case SerialPortEvent.DATA_AVAILABLE: while (newData != -1) { try { newData = is.read();//This should eventually return a -1 if no data is available within a timeout.PROBLEM!! System.out.println("Got a byte from port:"+newData); if (newData == -1) { break; } } catch (IOException ex) { System.err.println(ex); return; } } break; } return; } /******************************************************************************************************************************************************************************/ Thanks and regards, Ravi From michael.erskine at ketech.com Wed Feb 3 02:26:50 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 09:26:50 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From michael.erskine at ketech.com Wed Feb 3 05:03:30 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 12:03:30 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > Michael Erskine > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > > Your event handler should handle the event and return immediately so that its > controlling thread can handle other events. I recommend a single read in the > following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) > reads all available bytes up to the size of the buffer returning the number of > bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } After posting this I considered the glaring possibility of the rawbuf read buffer being too small to receive all the available bytes and perhaps skipping data: after all, I'm guessing that is why we see so many posts asking for help with blocking implementations of read event handlers looping on "while(bytes are available)". I've spent this morning writing an extensive multi-threaded unit test suite that includes tests with a tiny buffer compared to the amount of data available and found that no data was being skipped. I now want to know why! The SerialPortEvent.DATA_AVAILABLE event must be being fired again if there is more data available on the input stream. If that is the case then it should be heavily documented with good examples in the wiki to avoid the types of developer anguish we see so regularly. BTW: I'm not at liberty to post the JUnit tests as they use my company's unit test suite framework. Regards, Michael Erskine. From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 06:18:04 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 18:48:04 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Hello Michael, I tried out your suggestion but the problem is that the read(rawbuf) blocks until the entire length of the rawbuf array has been read (blocking). I cannot decide on a reasonable size of the array because it varies from 2 bytes to as much as 50 byes (i'm communicating with a modem,each response is of a different length), which is why i wanted to use non blocking calls. But on a side note, read(byte[]) in turn calls the read() in a loop.In the native C function, the read is supposed to return a -1 upon timeout.But my driver does not support timeout.The default timeout value is zero and the linux select call upon zero time out causes an infinite wait.What am i missing...... Thanks and regards, Ravi Date: Wed, 3 Feb 2010 09:26:50 +0000 From: Michael Erskine To: "rxtx at qbang.org" Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: Content-Type: text/plain; charset="us-ascii" > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From m.kirkland at comcast.net Wed Feb 3 06:46:03 2010 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 3 Feb 2010 05:46:03 -0800 Subject: [Rxtx] One port blocking another port In-Reply-To: References: Message-ID: <68768633814F4D7D86761D34F0764FE0@bengal.net> It turns out this is caused by having the RTS/CTS flow control turned on and me not providing a true on the RTS pin. Somehow it seems the port timing out on a read allows the write to proceed. This is not an issue for my application but I wonder if the write should not proceed until the RTS pin is true even if a read times out. mk -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Monday, January 25, 2010 7:48 PM To: Mike Kirkland Cc: rxtx at qbang.org Subject: Re: [Rxtx] One port blocking another port On Mon, 25 Jan 2010, Mike Kirkland wrote: > > Hi All, > > ? > > I have a program that reads from one com port and writes to another com > port. It also does the same thing in reverse (reads from the second com port > and writes to the first one. It basically ties two com ports together. > > ? > > One port is very chatty and has a consent stream of data. The other port has > very little data. > > ? > > Both ports use a 5000 ms (5 second) time out. > > ? > > The issue I am having is that is appears that the first port?s write to the > second port is blocked while the second port is waiting for input. The first > port?s write proceeds only after the second port has timed out. > > ? > > I suppose I could have something twisted around in my code but I was > wondering if this is a know issue? > Hi Kirk, I've not seen a report like this. Perhaps some simple reproduction code will reveal a problem on your end or help us identify a problem in rxtx. I think there are several users doing multiport communication. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Wed Feb 3 07:03:58 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:03:58 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Message-ID: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> 2010/2/3 Ravishankar N > Hello Michael, > [..] > But on a side note, read(byte[]) in turn calls the read() in a loop.In the > native C function, the read is supposed to return a -1 upon timeout.But my > driver > does not support timeout.The default timeout value is zero and the linux > select call upon zero time out causes an infinite wait.What am i > missing...... > > When I have tested RXTX between platforms, I have observed "hangup" inside JNI driver when no data in Linux, is normal thing. Solution was setting the timeout for RXTX when no data from JNI driver. Something like that: commPort.enableReceiveTimeout(10); And it works perfect.... The only difference is that I am NOT using events - I am using continous read in separate thread and if data is available, is parsed and transferred to application using exception. Regards Mariusz > Thanks and regards, > Ravi > > Date: Wed, 3 Feb 2010 09:26:50 +0000 > From: Michael Erskine > To: "rxtx at qbang.org" > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > Message-ID: > > > Content-Type: text/plain; charset="us-ascii" > > > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of > > Ravishankar N > > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > > > My serial port driver(apparently) does not support receive timeout.I > > registered an event listener for DATA_AVAILABLE. However, the control > never > > seems to come out of the 'while' loop.Shouldn't the > > InputStream.read return a '-1' immediately if no data is available (this > seems > > to be the default operation)? > > Your event handler should handle the event and return immediately so that > its controlling thread can handle other events. I recommend a single read in > the following manner: rawbuf is a byte[] of "reasonable" size and the > read(byte[]) reads all available bytes up to the size of the buffer > returning the number of bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } > > This style of reading has worked for me with RXTX on Linux and Windows XP > for a good few years now in railway industry communications systems. Any > timeouts (largely unnecessary in my applications) can be handled elsewhere, > usually at a higher layer. > > Regards, > Michael Erskine. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Feb 3 07:22:55 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 3 Feb 2010 09:22:55 -0500 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: I'm guessing that this is driver specific. I recently had to support a select()/poll() infrastructure for a linux serial DD, its certainly non trivial to support async IO, so I suspect the problem in this case has to do with missing poll infrastructure in the device driver. This also has to coupled with special open flags for the device (which is within the rxtx code) The key routines within a 2.6 kernel linux device driver are shown below (if you have access to it for your particular device) are indicated below (here is a snippet from my device driver c code that supports polling/select). User space code to test this shown below also, note that the device needs to be opened with the O_NONBLOCK option to support the select/poll api // device driver code ..... /* * File operations supported by this driver. */ static struct file_operations iop_fops = { .owner = THIS_MODULE, .check_flags= iop_check_flags, .ioctl = iop_ioctl, .open = iop_open, .poll = iop_poll, // SUPPORT FOR SELECT/POLL infrastructure .read = iop_read, .release = iop_release, .write = iop_write, }; /** * Select/poll/epoll infrastructure. * * @param file * @param wait * * @return */ static unsigned int iop_poll(struct file *filp, poll_table *wait) { struct iop_device *devp = (struct iop_device *)filp->private_data; // the poll_table wait arg is an opaque pointer poll_wait(filp, &devp->readq, wait); // return from poll indicating whether we have read/write data unsigned int mask = 0; if (kfifo_len(devp->rx_fifo)) { mask |= (POLLIN | POLLRDNORM); } // @JC We don't do select on write yet // if (kfifo_len(devp->tx_fifo)) { // mask |= (POLLOUT | POLLWRNORM); // } // Only print out while debugging // if (mask != 0) { // printk (KERN_INFO "%s: [%04x]\n", __FUNCTION__, mask); // } return mask; } /** * device driver blocking and non blocking read function. This * function reads the requested number of bytes from the read * kfifo blocking as required. * * @param filp * @param buf * @param count * @param f_pos * * @return */ static ssize_t iop_read(struct file *filp, char __user *buf, size_t count, loff_t * ppos) { // access appropriate device struct struct iop_device *devp = (struct iop_device *) filp->private_data; ssize_t retval; // support non blocking mode (default) by checking if the kfifo is empty first if ((kfifo_len(devp->rx_fifo)==0) && (filp->f_flags & O_NONBLOCK)) { return -EAGAIN; } // wait for rx_fifo to receive data via receive interrupts retval = wait_event_interruptible(devp->readq, kfifo_len(devp->rx_fifo) != 0); // check for some error condition if (retval) { printk (KERN_ERR "%s: wait_event_interruptible returned[%d]\n", __FUNCTION__, retval); return retval; } // copy max requested bytes from rx_fifo to device buffer // this may still leave bytes in the kfifo for a subsequent read // if we are reading in a loop retval = kfifo_get(devp->rx_fifo, devp->rxbuf, count); // printk (KERN_INFO "%s: [%d] byte(s)\n", __FUNCTION__, retval); if (copy_to_user(buf, devp->rxbuf, retval)) { printk (KERN_ERR "%s: problem copying rx_fifo data to user buffer\n", __FUNCTION__); return -EFAULT; } return retval; } // a selection of my user space code reading via select()/poll()..... // user space open code iop_fd = ::open( deviceName.data(), O_RDWR | O_NONBLOCK); while ((bytes_to_expect - bytes_read) > 0) { // must reinitialize these between select calls fd_set readfds; FD_ZERO( &readfds ); FD_SET( iop_fd, &readfds ); // 1s sec read polling timeout struct timeval timeout; timeout.tv_sec = 1; timeout.tv_usec = 0; int rc = select( FD_SETSIZE, &readfds, NULL, NULL, &timeout ); // read from file when descriptor // indicates data available without blocking if ((rc > 0) && FD_ISSET(iop_fd, &readfds)) { // read into the appropriate offset within the rx_buf int temp = read(iop_fd, rx_buf + bytes_read, bytes_to_expect - bytes_read); if (!temp) { printf("EOF detected with %d bytes expected\n", bytes_to_expect - bytes_read); } else { bytes_read += temp; } } else if (rc < 0){ printf("%s: select on [%s], bytes_read[%d], errno=%d\n", __FUNCTION__, thread_args->device, bytes_read, errno); } else { printf("%s: select on [%s], bytes_read[%d], timeout\n", __FUNCTION__, thread_args->device, bytes_read); } } On Wed, Feb 3, 2010 at 9:03 AM, Mariusz Dec wrote: > > > 2010/2/3 Ravishankar N > >> Hello Michael, >> [..] >> >> But on a side note, read(byte[]) in turn calls the read() in a loop.In the >> native C function, the read is supposed to return a -1 upon timeout.But my >> driver >> does not support timeout.The default timeout value is zero and the linux >> select call upon zero time out causes an infinite wait.What am i >> missing...... >> >> > When I have tested RXTX between platforms, I have observed "hangup" inside > JNI driver when no data in Linux, is normal thing. > > Solution was setting the timeout for RXTX when no data from JNI driver. > > Something like that: > > commPort.enableReceiveTimeout(10); > > And it works perfect.... > > The only difference is that I am NOT using events - I am using continous > read in separate thread and if data is available, is parsed and transferred > to application using exception. > > Regards > Mariusz > > > >> Thanks and regards, >> Ravi >> >> Date: Wed, 3 Feb 2010 09:26:50 +0000 >> From: Michael Erskine >> To: "rxtx at qbang.org" >> Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? >> Message-ID: >> >> >> Content-Type: text/plain; charset="us-ascii" >> >> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >> Of >> > Ravishankar N >> > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? >> > >> > My serial port driver(apparently) does not support receive timeout.I >> > registered an event listener for DATA_AVAILABLE. However, the control >> never >> > seems to come out of the 'while' loop.Shouldn't the >> > InputStream.read return a '-1' immediately if no data is available (this >> seems >> > to be the default operation)? >> >> Your event handler should handle the event and return immediately so that >> its controlling thread can handle other events. I recommend a single read in >> the following manner: rawbuf is a byte[] of "reasonable" size and the >> read(byte[]) reads all available bytes up to the size of the buffer >> returning the number of bytes actually read... >> >> case SerialPortEvent.DATA_AVAILABLE: >> try { >> int i = is.read(rawbuf); >> if (i == -1) { >> << process EOF condition - should never happen >> >> return; >> } >> << process bytes (rawbuf, i); >> >> return; >> } catch (IOException e) { >> << promptly deal with exception >> >> return; >> } >> >> This style of reading has worked for me with RXTX on Linux and Windows XP >> for a good few years now in railway industry communications systems. Any >> timeouts (largely unnecessary in my applications) can be handled elsewhere, >> usually at a higher layer. >> >> Regards, >> Michael Erskine. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Feb 3 07:33:27 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:33:27 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: <73a89f361002030633j682610afia48dc7accd8e049b@mail.gmail.com> 2010/2/3 John Coffey > I'm guessing that this is driver specific. I recently had to support a > select()/poll() infrastructure for a linux serial DD, its certainly non > trivial to support async IO, so I suspect the problem in this case has to do > with missing poll infrastructure in the device driver. This also has to > coupled with special open flags for the device (which is within the rxtx > code) > > Yes, you are right, it may be driver specific, but in my case I haven't changed blocking JNI driver. I have added ONLY one call to RXTX method mentioned in my previous post and blocking (as seen as from Java app) gone out... Maybe this is not elegant, but works without problem in my app. I am using only FTDI chips and their drivers from couple of years and maybe this is the kind of the way to have no many problems with serial as well? Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From andyrxtx at g0poy.co.uk Wed Feb 3 11:09:04 2010 From: andyrxtx at g0poy.co.uk (andyrxtx at g0poy.co.uk) Date: Wed, 3 Feb 2010 18:09:04 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes Message-ID: <20100203180904.164f24dd@workstation.site> ?Hello RXTX group, I have just joined this group, and this is my first posting. I wanted to pass on some information regarding rxtx, so apologies if this has been brought up before. I have searched back through the archives but nothing specific came up. I am not a Java programmer, and I only came across rxtx a few days ago. I use a piece of test equipment called a miniVNA http://www.miniradiosolutions.com/ This is a serial USB controlled instrument, and it has control software available for MS windows, and a very old and now non-working Linux application. A few days ago Dietmar, DL2SBA released a Java application to control the miniVNA, obviously this application makes use of rxtx. The program worked fine on Windows, so I set about installing it onto Linux. I use SUSE11.1 After a few false starts, I got the system running fairly easily, sorting out the file locking by adding the uucp group to the users account as suggested (I used the 2.2pre binary files) I then passed the install instructions onto another miniVNA user, who also uses SUSE, but he ran into problems. To cut a long story short, he was also having file lock problems, but the uucp fix did not work. Digging into his system I found that there have been some changes in SUSE 11.2. tty ports are now assigned to the dialout group rather than uucp. A hint in the rxtx INSTALL file, suggested that var/lock needs to be checked, so: SUSE 11.1, var/lock is root:uucp SUSE 11.2 var/lock is root:root A search on Google brought up several comments regarding this, and also a bugzilla entry. https://bugzilla.novell.com/show_bug.cgi?id=552095 However from reading the various posts, some of which are in the bugzilla entry, it appears that many distros may be, or have changed to this configuration, and this will undoubtedly break several things, rxtx included. I solved my fellow SUSE users problem by compiling the rxtx libs with the no lock file option during configure, and that solved his problem. As this issue will probably take some time to get resolved across all the various Linux distros, it might be worth considering changing the default on the Linux build of rxtx not to use lockfiles, or provide the two versions of the lib in the binary archive. Thanks for your indulgence Andy From damorales at gmail.com Wed Feb 3 11:33:23 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 15:33:23 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203180904.164f24dd@workstation.site> References: <20100203180904.164f24dd@workstation.site> Message-ID: Hi I had the same problem in Mandriva 2010 and yes, adding the user to the uucp group did not work as it used to be in earlier versions of linux distros, causing RXTX to not work as non root user. The problem appears because the existense of UDEV, now you MUST add a RULE so the group (uucp or whatever) have access (Read, Write, Execute) to the Serial Port. To solve the problem, without needing to recompile RXTX, you must add a rule to grant permissions (0666) to the group for the device or port (tty*, ttyUSB*, etc). I do not remember now what is the line i added but when i come back home i will give it to you (i am at work now). Greetings ! 2010/2/3 > Hello RXTX group, > > I have just joined this group, and this is my first posting. > I wanted to pass on some information regarding rxtx, so apologies if > this has been brought up before. I have searched back through the > archives but nothing specific came up. > > I am not a Java programmer, and I only came across rxtx a few days ago. > > I use a piece of test equipment called a miniVNA > http://www.miniradiosolutions.com/ > > This is a serial USB controlled instrument, and it has control software > available for MS windows, and a very old and now non-working Linux > application. > > A few days ago Dietmar, DL2SBA released a Java application to control the > miniVNA, obviously this application makes use of rxtx. > > The program worked fine on Windows, so I set about installing it onto > Linux. I use SUSE11.1 After a few false starts, I got the system running > fairly easily, sorting out the file locking by adding the uucp group to > the users account as suggested (I used the 2.2pre binary files) I then > passed the install instructions onto another miniVNA user, who also uses > SUSE, but he ran into problems. To cut a long story short, he was > also having file lock problems, but the uucp fix did not work. Digging > into his system I found that there have been some changes in SUSE 11.2. > > tty ports are now assigned to the dialout group rather than uucp. > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > checked, so: > > SUSE 11.1, var/lock is root:uucp > SUSE 11.2 var/lock is root:root > > A search on Google brought up several comments regarding this, and also > a bugzilla entry. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > However from reading the various posts, some of which are in the bugzilla > entry, it appears that many distros may be, or have changed to this > configuration, and this will undoubtedly break several things, rxtx > included. > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > no lock file option during configure, and that solved his problem. > > As this issue will probably take some time to get resolved across all the > various Linux distros, it might be worth considering changing the default > on the Linux build of rxtx not to use lockfiles, or provide the two > versions of the lib in the binary archive. > > Thanks for your indulgence > > Andy > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Wed Feb 3 12:07:02 2010 From: andy at g0poy.com (Andy Eskelson) Date: Wed, 3 Feb 2010 19:07:02 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> Message-ID: <20100203190702.1b0e7015@workstation.site> Thanks Daniel, I am aware of the permissions problem, I have had a udev rules to solve this for other programs for some time. . I don't think that this is the same problem. as far as I can understand things, the lock files are written in var/lock. Previously var/lock and dev/tty-whatever were the same group. Now with var/lock owned by and with a group of root:root anything other than root cannot create a lock file. Even minicom is broken by this change. This change is going to have quite a few knock-on effects I think. Andy On Wed, 3 Feb 2010 15:33:23 -0300 Daniel Morales Salas wrote: > Hi > > I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > group did not work as it used to be in earlier versions of linux distros, > causing RXTX to not work as non root user. > > The problem appears because the existense of UDEV, now you MUST add a RULE > so the group (uucp or whatever) have access (Read, Write, Execute) to the > Serial Port. > > To solve the problem, without needing to recompile RXTX, you must add a rule > to grant permissions (0666) to the group for the device or port (tty*, > ttyUSB*, etc). I do not remember now what is the line i added but when i > come back home i will give it to you (i am at work now). > > Greetings ! > > 2010/2/3 > > > Hello RXTX group, > > > > I have just joined this group, and this is my first posting. > > I wanted to pass on some information regarding rxtx, so apologies if > > this has been brought up before. I have searched back through the > > archives but nothing specific came up. > > > > I am not a Java programmer, and I only came across rxtx a few days ago. > > > > I use a piece of test equipment called a miniVNA > > http://www.miniradiosolutions.com/ > > > > This is a serial USB controlled instrument, and it has control software > > available for MS windows, and a very old and now non-working Linux > > application. > > > > A few days ago Dietmar, DL2SBA released a Java application to control the > > miniVNA, obviously this application makes use of rxtx. > > > > The program worked fine on Windows, so I set about installing it onto > > Linux. I use SUSE11.1 After a few false starts, I got the system running > > fairly easily, sorting out the file locking by adding the uucp group to > > the users account as suggested (I used the 2.2pre binary files) I then > > passed the install instructions onto another miniVNA user, who also uses > > SUSE, but he ran into problems. To cut a long story short, he was > > also having file lock problems, but the uucp fix did not work. Digging > > into his system I found that there have been some changes in SUSE 11.2. > > > > tty ports are now assigned to the dialout group rather than uucp. > > > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > checked, so: > > > > SUSE 11.1, var/lock is root:uucp > > SUSE 11.2 var/lock is root:root > > > > A search on Google brought up several comments regarding this, and also > > a bugzilla entry. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > However from reading the various posts, some of which are in the bugzilla > > entry, it appears that many distros may be, or have changed to this > > configuration, and this will undoubtedly break several things, rxtx > > included. > > > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > > no lock file option during configure, and that solved his problem. > > > > As this issue will probably take some time to get resolved across all the > > various Linux distros, it might be worth considering changing the default > > on the Linux build of rxtx not to use lockfiles, or provide the two > > versions of the lib in the binary archive. > > > > Thanks for your indulgence > > > > Andy > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From thisdyingdream at gmail.com Wed Feb 3 12:32:35 2010 From: thisdyingdream at gmail.com (Steven Harms) Date: Wed, 3 Feb 2010 14:32:35 -0500 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203190702.1b0e7015@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: This is currently a bug in OpenSUSE that affects more than just rxtx, and is a result of unified udev rules. You can work around this by making udev change the group back to uucp until something more happens. https://bugzilla.novell.com/show_bug.cgi?id=552095 Thanks, Steve On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > Thanks Daniel, > > I am aware of the permissions problem, I have had a udev rules to solve > this for other programs for some time. > . > I don't think that this is the same problem. as far as I can understand > things, the lock files are written in var/lock. Previously var/lock and > dev/tty-whatever were the same group. Now with var/lock owned by and with > a group of root:root anything other than root cannot create a lock > file. Even minicom is broken by this change. > > This change is going to have quite a few knock-on effects I think. > > > Andy > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > Daniel Morales Salas wrote: > >> Hi >> >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp >> group did not work as it used to be in earlier versions of linux distros, >> causing RXTX to not work as non root user. >> >> The problem appears because the existense of UDEV, now you MUST add a RULE >> so the group (uucp or whatever) have access (Read, Write, Execute) to the >> Serial Port. >> >> To solve the problem, without needing to recompile RXTX, you must add a rule >> to grant permissions (0666) to the group for the device or port (tty*, >> ttyUSB*, etc). I do not remember now what is the line i added but when i >> come back home i will give it to you (i am at work now). >> >> Greetings ! >> >> 2010/2/3 >> >> > Hello RXTX group, >> > >> > I have just joined this group, and this is my first posting. >> > I wanted to pass on ?some information regarding rxtx, so apologies if >> > this has been brought up before. I have searched back through the >> > archives but nothing specific came up. >> > >> > I am not a Java programmer, and I only came across rxtx a few days ago. >> > >> > I use a piece of test equipment called a miniVNA >> > http://www.miniradiosolutions.com/ >> > >> > This is a serial USB controlled instrument, and it has control software >> > available for MS windows, and a very old and now non-working Linux >> > application. >> > >> > A few days ago Dietmar, DL2SBA released a Java application to control the >> > miniVNA, obviously this application makes use of rxtx. >> > >> > The program worked fine on Windows, so I set about installing it onto >> > Linux. I use SUSE11.1 After a few false starts, I got the system running >> > fairly easily, sorting out the file locking by adding the uucp group to >> > the users account as suggested (I used the 2.2pre binary files) I then >> > passed the install instructions onto another miniVNA user, who also uses >> > SUSE, but he ran into problems. To cut a long story short, he was >> > also having file lock problems, but the uucp fix did not work. Digging >> > into his system I found that there have been some changes in SUSE 11.2. >> > >> > tty ports are now assigned to the dialout group rather than uucp. >> > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be >> > checked, so: >> > >> > SUSE 11.1, var/lock is root:uucp >> > SUSE 11.2 var/lock is root:root >> > >> > A search on Google brought up several comments regarding this, and also >> > a ?bugzilla entry. >> > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 >> > >> > However from reading the various posts, some of which are in the bugzilla >> > entry, it appears that many distros may be, or have changed to this >> > configuration, and this will undoubtedly break several things, rxtx >> > included. >> > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the >> > no lock file option during configure, and that solved his problem. >> > >> > As this issue will probably take some time to get resolved across all the >> > various Linux distros, it might be worth considering changing the default >> > on the Linux build of rxtx not to use lockfiles, or provide the two >> > versions of the lib in the binary archive. >> > >> > Thanks for your indulgence >> > >> > Andy >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> >> >> >> -- >> Atte: >> Daniel Dario Morales Salas >> Ingeniero Civil en Computaci?n e Inform?tica >> Tel?fono: 02 684 3417 >> Celular: 09 643 1802 >> Santiago, Chile > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 WWW: http://www.sharms.org/blog From andy at g0poy.com Wed Feb 3 17:58:29 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 00:58:29 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: <20100204005829.7dc944e1@workstation.site> Thanks Steve, changing the serial ports back the uucp is not a big problem. I have a udev rule that can be easily modified already. However I cannot see any way of dealing with the var/lock problem apart from making it writable to all. Any thoughts? Andy On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms wrote: > This is currently a bug in OpenSUSE that affects more than just rxtx, > and is a result of unified udev rules. You can work around this by > making udev change the group back to uucp until something more > happens. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > Thanks, > > Steve > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > Thanks Daniel, > > > > I am aware of the permissions problem, I have had a udev rules to solve > > this for other programs for some time. > > . > > I don't think that this is the same problem. as far as I can understand > > things, the lock files are written in var/lock. Previously var/lock and > > dev/tty-whatever were the same group. Now with var/lock owned by and with > > a group of root:root anything other than root cannot create a lock > > file. Even minicom is broken by this change. > > > > This change is going to have quite a few knock-on effects I think. > > > > > > Andy > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > Daniel Morales Salas wrote: > > > >> Hi > >> > >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > >> group did not work as it used to be in earlier versions of linux distros, > >> causing RXTX to not work as non root user. > >> > >> The problem appears because the existense of UDEV, now you MUST add a RULE > >> so the group (uucp or whatever) have access (Read, Write, Execute) to the > >> Serial Port. > >> > >> To solve the problem, without needing to recompile RXTX, you must add a rule > >> to grant permissions (0666) to the group for the device or port (tty*, > >> ttyUSB*, etc). I do not remember now what is the line i added but when i > >> come back home i will give it to you (i am at work now). > >> > >> Greetings ! > >> > >> 2010/2/3 > >> > >> > Hello RXTX group, > >> > > >> > I have just joined this group, and this is my first posting. > >> > I wanted to pass on ?some information regarding rxtx, so apologies if > >> > this has been brought up before. I have searched back through the > >> > archives but nothing specific came up. > >> > > >> > I am not a Java programmer, and I only came across rxtx a few days ago. > >> > > >> > I use a piece of test equipment called a miniVNA > >> > http://www.miniradiosolutions.com/ > >> > > >> > This is a serial USB controlled instrument, and it has control software > >> > available for MS windows, and a very old and now non-working Linux > >> > application. > >> > > >> > A few days ago Dietmar, DL2SBA released a Java application to control the > >> > miniVNA, obviously this application makes use of rxtx. > >> > > >> > The program worked fine on Windows, so I set about installing it onto > >> > Linux. I use SUSE11.1 After a few false starts, I got the system running > >> > fairly easily, sorting out the file locking by adding the uucp group to > >> > the users account as suggested (I used the 2.2pre binary files) I then > >> > passed the install instructions onto another miniVNA user, who also uses > >> > SUSE, but he ran into problems. To cut a long story short, he was > >> > also having file lock problems, but the uucp fix did not work. Digging > >> > into his system I found that there have been some changes in SUSE 11.2. > >> > > >> > tty ports are now assigned to the dialout group rather than uucp. > >> > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > >> > checked, so: > >> > > >> > SUSE 11.1, var/lock is root:uucp > >> > SUSE 11.2 var/lock is root:root > >> > > >> > A search on Google brought up several comments regarding this, and also > >> > a ?bugzilla entry. > >> > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > >> > > >> > However from reading the various posts, some of which are in the bugzilla > >> > entry, it appears that many distros may be, or have changed to this > >> > configuration, and this will undoubtedly break several things, rxtx > >> > included. > >> > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the > >> > no lock file option during configure, and that solved his problem. > >> > > >> > As this issue will probably take some time to get resolved across all the > >> > various Linux distros, it might be worth considering changing the default > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > >> > versions of the lib in the binary archive. > >> > > >> > Thanks for your indulgence > >> > > >> > Andy > >> > > >> > _______________________________________________ > >> > Rxtx mailing list > >> > Rxtx at qbang.org > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > >> > >> > >> > >> -- > >> Atte: > >> Daniel Dario Morales Salas > >> Ingeniero Civil en Computaci?n e Inform?tica > >> Tel?fono: 02 684 3417 > >> Celular: 09 643 1802 > >> Santiago, Chile > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > WWW: http://www.sharms.org/blog From damorales at gmail.com Wed Feb 3 18:26:38 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 22:26:38 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100204005829.7dc944e1@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: Hello I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva 2010 this is what i get: drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ and i don't have ANY problem with lock files and RXTX in my java software. All i had to do was add this rule to udev: # serial KERNEL=="tty*", GROUP="uucp", MODE="0666" and that was all. Of course my user (metalklesk) is part of uucp group. I did not make /var/lock writable to all users. Greetings ! 2010/2/3 Andy Eskelson > Thanks Steve, > > changing the serial ports back the uucp is not a big problem. I have a > udev rule that can be easily modified already. However I cannot see any > way of dealing with the var/lock problem apart from making it writable to > all. Any thoughts? > > Andy > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > wrote: > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > and is a result of unified udev rules. You can work around this by > > making udev change the group back to uucp until something more > > happens. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > Thanks, > > > > Steve > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > Thanks Daniel, > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > this for other programs for some time. > > > . > > > I don't think that this is the same problem. as far as I can understand > > > things, the lock files are written in var/lock. Previously var/lock and > > > dev/tty-whatever were the same group. Now with var/lock owned by and > with > > > a group of root:root anything other than root cannot create a lock > > > file. Even minicom is broken by this change. > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > Daniel Morales Salas wrote: > > > > > >> Hi > > >> > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > the uucp > > >> group did not work as it used to be in earlier versions of linux > distros, > > >> causing RXTX to not work as non root user. > > >> > > >> The problem appears because the existense of UDEV, now you MUST add a > RULE > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > the > > >> Serial Port. > > >> > > >> To solve the problem, without needing to recompile RXTX, you must add > a rule > > >> to grant permissions (0666) to the group for the device or port (tty*, > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > i > > >> come back home i will give it to you (i am at work now). > > >> > > >> Greetings ! > > >> > > >> 2010/2/3 > > >> > > >> > Hello RXTX group, > > >> > > > >> > I have just joined this group, and this is my first posting. > > >> > I wanted to pass on some information regarding rxtx, so apologies > if > > >> > this has been brought up before. I have searched back through the > > >> > archives but nothing specific came up. > > >> > > > >> > I am not a Java programmer, and I only came across rxtx a few days > ago. > > >> > > > >> > I use a piece of test equipment called a miniVNA > > >> > http://www.miniradiosolutions.com/ > > >> > > > >> > This is a serial USB controlled instrument, and it has control > software > > >> > available for MS windows, and a very old and now non-working Linux > > >> > application. > > >> > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > control the > > >> > miniVNA, obviously this application makes use of rxtx. > > >> > > > >> > The program worked fine on Windows, so I set about installing it > onto > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > running > > >> > fairly easily, sorting out the file locking by adding the uucp group > to > > >> > the users account as suggested (I used the 2.2pre binary files) I > then > > >> > passed the install instructions onto another miniVNA user, who also > uses > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > >> > also having file lock problems, but the uucp fix did not work. > Digging > > >> > into his system I found that there have been some changes in SUSE > 11.2. > > >> > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > >> > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > >> > checked, so: > > >> > > > >> > SUSE 11.1, var/lock is root:uucp > > >> > SUSE 11.2 var/lock is root:root > > >> > > > >> > A search on Google brought up several comments regarding this, and > also > > >> > a bugzilla entry. > > >> > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > >> > > > >> > However from reading the various posts, some of which are in the > bugzilla > > >> > entry, it appears that many distros may be, or have changed to this > > >> > configuration, and this will undoubtedly break several things, rxtx > > >> > included. > > >> > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > with the > > >> > no lock file option during configure, and that solved his problem. > > >> > > > >> > As this issue will probably take some time to get resolved across > all the > > >> > various Linux distros, it might be worth considering changing the > default > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > >> > versions of the lib in the binary archive. > > >> > > > >> > Thanks for your indulgence > > >> > > > >> > Andy > > >> > > > >> > _______________________________________________ > > >> > Rxtx mailing list > > >> > Rxtx at qbang.org > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > >> > > > >> > > >> > > >> > > >> -- > > >> Atte: > > >> Daniel Dario Morales Salas > > >> Ingeniero Civil en Computaci?n e Inform?tica > > >> Tel?fono: 02 684 3417 > > >> Celular: 09 643 1802 > > >> Santiago, Chile > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at qbang.org > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > -- > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > WWW: http://www.sharms.org/blog > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Thu Feb 4 05:31:46 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 12:31:46 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: <20100204123146.6cffeb67@workstation.site> Thank's for the confirmation. Something odd is going on somewhere in SUSE 11.2. I'll have to build up a local SUSE11.2 system to see if I can nail down exactly what is going on. Something is blocking the lockfiles in var/lock. The net is nice, but it's a bit difficult trying to work out what is going on what the machine in question is in Germany and I'm in the UK :-) Andy On Wed, 3 Feb 2010 22:26:38 -0300 Daniel Morales Salas wrote: > Hello > > I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva > 2010 this is what i get: > > drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ > > and i don't have ANY problem with lock files and RXTX in my java software. > All i had to do was add this rule to udev: > > # serial > KERNEL=="tty*", GROUP="uucp", MODE="0666" > > and that was all. Of course my user (metalklesk) is part of uucp group. > I did not make /var/lock writable to all users. > > Greetings ! > > 2010/2/3 Andy Eskelson > > > Thanks Steve, > > > > changing the serial ports back the uucp is not a big problem. I have a > > udev rule that can be easily modified already. However I cannot see any > > way of dealing with the var/lock problem apart from making it writable to > > all. Any thoughts? > > > > Andy > > > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > > wrote: > > > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > > and is a result of unified udev rules. You can work around this by > > > making udev change the group back to uucp until something more > > > happens. > > > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > > > Thanks, > > > > > > Steve > > > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > > Thanks Daniel, > > > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > > this for other programs for some time. > > > > . > > > > I don't think that this is the same problem. as far as I can understand > > > > things, the lock files are written in var/lock. Previously var/lock and > > > > dev/tty-whatever were the same group. Now with var/lock owned by and > > with > > > > a group of root:root anything other than root cannot create a lock > > > > file. Even minicom is broken by this change. > > > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > > Daniel Morales Salas wrote: > > > > > > > >> Hi > > > >> > > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > > the uucp > > > >> group did not work as it used to be in earlier versions of linux > > distros, > > > >> causing RXTX to not work as non root user. > > > >> > > > >> The problem appears because the existense of UDEV, now you MUST add a > > RULE > > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > > the > > > >> Serial Port. > > > >> > > > >> To solve the problem, without needing to recompile RXTX, you must add > > a rule > > > >> to grant permissions (0666) to the group for the device or port (tty*, > > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > > i > > > >> come back home i will give it to you (i am at work now). > > > >> > > > >> Greetings ! > > > >> > > > >> 2010/2/3 > > > >> > > > >> > Hello RXTX group, > > > >> > > > > >> > I have just joined this group, and this is my first posting. > > > >> > I wanted to pass on some information regarding rxtx, so apologies > > if > > > >> > this has been brought up before. I have searched back through the > > > >> > archives but nothing specific came up. > > > >> > > > > >> > I am not a Java programmer, and I only came across rxtx a few days > > ago. > > > >> > > > > >> > I use a piece of test equipment called a miniVNA > > > >> > http://www.miniradiosolutions.com/ > > > >> > > > > >> > This is a serial USB controlled instrument, and it has control > > software > > > >> > available for MS windows, and a very old and now non-working Linux > > > >> > application. > > > >> > > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > > control the > > > >> > miniVNA, obviously this application makes use of rxtx. > > > >> > > > > >> > The program worked fine on Windows, so I set about installing it > > onto > > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > > running > > > >> > fairly easily, sorting out the file locking by adding the uucp group > > to > > > >> > the users account as suggested (I used the 2.2pre binary files) I > > then > > > >> > passed the install instructions onto another miniVNA user, who also > > uses > > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > > >> > also having file lock problems, but the uucp fix did not work. > > Digging > > > >> > into his system I found that there have been some changes in SUSE > > 11.2. > > > >> > > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > > >> > > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > > >> > checked, so: > > > >> > > > > >> > SUSE 11.1, var/lock is root:uucp > > > >> > SUSE 11.2 var/lock is root:root > > > >> > > > > >> > A search on Google brought up several comments regarding this, and > > also > > > >> > a bugzilla entry. > > > >> > > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > >> > > > > >> > However from reading the various posts, some of which are in the > > bugzilla > > > >> > entry, it appears that many distros may be, or have changed to this > > > >> > configuration, and this will undoubtedly break several things, rxtx > > > >> > included. > > > >> > > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > > with the > > > >> > no lock file option during configure, and that solved his problem. > > > >> > > > > >> > As this issue will probably take some time to get resolved across > > all the > > > >> > various Linux distros, it might be worth considering changing the > > default > > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > > >> > versions of the lib in the binary archive. > > > >> > > > > >> > Thanks for your indulgence > > > >> > > > > >> > Andy > > > >> > > > > >> > _______________________________________________ > > > >> > Rxtx mailing list > > > >> > Rxtx at qbang.org > > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > > >> > > > > >> > > > >> > > > >> > > > >> -- > > > >> Atte: > > > >> Daniel Dario Morales Salas > > > >> Ingeniero Civil en Computaci?n e Inform?tica > > > >> Tel?fono: 02 684 3417 > > > >> Celular: 09 643 1802 > > > >> Santiago, Chile > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at qbang.org > > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > > > -- > > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > > > WWW: http://www.sharms.org/blog > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From Bob_Jacobsen at lbl.gov Thu Feb 4 09:26:49 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Thu, 4 Feb 2010 08:26:49 -0800 Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 Message-ID: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're using RXTX-2.2pre2, although it emits the known message about "Version mismatch". WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 After the usual messing around, we've got it working on 11 Windows versions, multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ have things working rarely say so, so I don't know whether anybody has gotten it to work on 10.4 or not. The problem encountered is this: dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib dyld: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib followed by the JVM crashing hard. I've got those dump files if that would help. Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If so, is there a patch I can get and build? Thanks Bob -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From tjarvi at qbang.org Thu Feb 4 14:22:21 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 4 Feb 2010 14:22:21 -0700 (MST) Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 In-Reply-To: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> References: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> Message-ID: On Thu, 4 Feb 2010, Bob Jacobsen wrote: > We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're > using RXTX-2.2pre2, although it emits the known message about "Version > mismatch". > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > > After the usual messing around, we've got it working on 11 Windows versions, > multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with > a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ > have things working rarely say so, so I don't know whether anybody has gotten > it to work on 10.4 or not. > > The problem encountered is this: > > dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > dyld: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > followed by the JVM crashing hard. I've got those dump files if that would > help. > > Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If > so, is there a patch I can get and build? > Hi Bob, I talked to a coworker about the problem you ran into. It appears that it is possible to target 'older' Mac systems through makefile configuration changes. "Configuring a Makefile-Based Project If you have a makefile-based project, you can also take advantage of SDK-based development, by adding the appropriate options to your compile and link commands. Using SDKs in makefile-based projects requires GCC 4.0 or later. To choose an SDK, you use the -isysroot option with the compiler and the -syslibroot option with the linker. Both options require that you specify the full path to the desired SDK directory. To set the Deployment OS version in a makefile, use a makefile variable of the form: ENVP= MACOSX_DEPLOYMENT_TARGET=10.4. To use this variable in your makefile, include it in front of your compile and link commands." http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html Or build on the oldest system you want to support. -- Trent Jarvi tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Thu Feb 4 14:56:19 2010 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Thu, 4 Feb 2010 14:56:19 -0700 Subject: [Rxtx] RXTX on 64 Bit Redhat In-Reply-To: References: <4ec9eab61001281448g3dd84910r867619948a4e0d7a@mail.gmail.com> Message-ID: Trent -- Finally fixed all my build related issues. I ran into another issue. On one of my machines my JDK is returning multiple folders for the "java.ext.dirs" (java.ext.dirs -> /opt/jdk1.6.0_17/jre/lib/ext:/usr/java/packages/lib/ext) system property. As a result my JVM wasn't able to detect the gnu.io.rxtx.properties. I am attaching a patch for RXTXCommDriver.java file to check for multiple locations. Also i have to assign permission 660 to all my dev ports to be located by RXTX. Pawan ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 5:12 PM To: Trent Jarvi Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Here is the error i get when i build the src from release-2-1-7 -bash-3.2$ make ( \ \ cd i686-pc-linux-gnu; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/ jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I/opt/jav a1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec - c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialImp.lo;\ if [ "Serial" = "Serial" ]; then \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I /opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_tim espec -c /home/jb_stg/rxtx/rxtx-devel/./src/fuserImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ else \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo; \ fi; \ ) gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/inclu de -I/opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need _timespec -c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -fPIC -DPIC -o /hom e/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/.libs/SerialImp.o /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:25:29: error: gnu_io_RXTXPort.h: No such file or directory In file included from /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:113: /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:91: error: expected specifier-qua lifier-list before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'jobject' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:408: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:409: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:410: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:411: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:415: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:416: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:417: error: expected '=', ',', '; ', 'asm' or '__attribute__' before 'is_interrupted' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:418: error: expected declaration specifiers or '...' before 'jint' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:424: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:441: error: expected ')' before ' *' token ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 4:57 PM To: Santosh Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Santosh -- Thank you. That fixed the issue. All -- What CVS branch or release should i use to get the latest RXTX src code. Pawan ________________________________ From: Santosh [mailto:santosh.ry at gmail.com] Sent: Thursday, January 28, 2010 3:49 PM To: Kharbanda, Pawan Cc: Trent Jarvi; rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat error "./configure: /bin/sh^M: bad interpreter: No such file or directory". I think you need to run dos2unix on script files before compiling. Thanks, Santosh On Thu, Jan 28, 2010 at 5:33 PM, Kharbanda, Pawan > wrote: Trent -- We are upgrading our exisiting OS and JDK on a project that rely heavily on RXTX api's. We are now using JDK1.6 32 bit (build 1.6.0_17-b04) and RedHat 5 on a 64 bit machine. Linux tocrhstg02.dot.state.co.us 2.6.18-164.6.1.el5 #1 SMP Tue Oct 27 11:30:06 EDT 2009 i686 i686 i386 GNU/Linux Red Hat Enterprise Linux Server release 5.4 (Tikanga) I tried to run version 2.1.7 r2 on it but not able to see any of my Digi ports I was able to access only /dev/ttyS0 (physical ports). Not sure if the problem is with the Digi driver or RXTX. I tried to open a Digi port with minicom and it worked fine. I also tried to get latest from CVS (rxtx-devel) and when I do "configure" I see this error "./configure: /bin/sh^M: bad interpreter: No such file or directory". Can someone please help me with this? Thanks for the help. Pawan _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch.txt URL: From juan.vicente.l.g at gmail.com Sat Feb 13 04:44:17 2010 From: juan.vicente.l.g at gmail.com (Juan Vicente Lopez Gutierrez) Date: Sat, 13 Feb 2010 12:44:17 +0100 Subject: [Rxtx] RXTX in macmini OSX 10.5 Message-ID: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> Hello. My name is Juanvi and I'm from Spain. I tried to launch a software created by me in the library CXR java to send information through the serial port and I can not make it work. In windows if I've done but not mac. I have a mac mini with OSX 10.5 and have read in the list of web mail that you CXR if you have managed to make it work on that operating system. I need you help me please. Do I make the mistake that shows me java: run: Stable Library =============================== Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 gnu.io.PortInUseException: Unknow Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:26) at TwoWatSerialComm.main(TwoWaySerialComm.java:106) Experimental: JNI_OnLoad called. GENERACION CORRECTA (total time: 0 seconds) I do not have permission to access the serial port, do not know. Os agradeceria much to sit down. A greeting and thanks. Pardon my English. Juanvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From juan.vicente.l.g at gmail.com Sat Feb 13 14:39:41 2010 From: juan.vicente.l.g at gmail.com (Juan Vicente Lopez Gutierrez) Date: Sat, 13 Feb 2010 22:39:41 +0100 Subject: [Rxtx] Fwd: RXTX in macmini OSX 10.5 In-Reply-To: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> References: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> Message-ID: <29405e5c1002131339m2059d169sdc8549ed9706a1af@mail.gmail.com> ---------- Forwarded message ---------- From: Juan Vicente Lopez Gutierrez Date: 2010/2/13 Subject: RXTX in macmini OSX 10.5 To: rxtx at qbang.org Hello. My name is Juanvi and I'm from Spain. I tried to launch a software created by me in the library CXR java to send information through the serial port and I can not make it work. In windows if I've done but not mac. I have a mac mini with OSX 10.5 and have read in the list of web mail that you CXR if you have managed to make it work on that operating system. I need you help me please. Do I make the mistake that shows me java: run: Stable Library =============================== Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 gnu.io.PortInUseException: Unknow Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:26) at TwoWatSerialComm.main(TwoWaySerialComm.java:106) Experimental: JNI_OnLoad called. GENERACION CORRECTA (total time: 0 seconds) I do not have permission to access the serial port, do not know. Os agradeceria much to sit down. A greeting and thanks. Pardon my English. Juanvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 01:02:21 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 13:32:21 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> My serial port driver(apparently) does not support receive timeout.I registered an event listener for DATA_AVAILABLE. However, the control never seems to come out of the 'while' loop.Shouldn't the InputStream.read return a '-1' immediately if no data is available (this seems to be the default operation)? This was tried on a x86 Linux desktop using rxtx-2.1-7 I've added the snippet for clarity: /******************************************************************************************************************************************************************************/ mySerialPort.enableReceiveThreshold(2000);//Trying to set a time limit for read calls System.out.println(mySerialPort.isReceiveTimeoutEnabled()); // I get FALSE, so its not supported on hardware. mySerialPort.addEventListener(this); mySerialPort.notifyOnDataAvailable(true);//register a event with //my SerialEvent listener implementation: public void serialEvent(SerialPortEvent arg0) { int newData=0; switch(arg0.getEventType()){ case SerialPortEvent.DATA_AVAILABLE: while (newData != -1) { try { newData = is.read();//This should eventually return a -1 if no data is available within a timeout.PROBLEM!! System.out.println("Got a byte from port:"+newData); if (newData == -1) { break; } } catch (IOException ex) { System.err.println(ex); return; } } break; } return; } /******************************************************************************************************************************************************************************/ Thanks and regards, Ravi From michael.erskine at ketech.com Wed Feb 3 02:26:50 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 09:26:50 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From michael.erskine at ketech.com Wed Feb 3 05:03:30 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 12:03:30 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > Michael Erskine > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > > Your event handler should handle the event and return immediately so that its > controlling thread can handle other events. I recommend a single read in the > following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) > reads all available bytes up to the size of the buffer returning the number of > bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } After posting this I considered the glaring possibility of the rawbuf read buffer being too small to receive all the available bytes and perhaps skipping data: after all, I'm guessing that is why we see so many posts asking for help with blocking implementations of read event handlers looping on "while(bytes are available)". I've spent this morning writing an extensive multi-threaded unit test suite that includes tests with a tiny buffer compared to the amount of data available and found that no data was being skipped. I now want to know why! The SerialPortEvent.DATA_AVAILABLE event must be being fired again if there is more data available on the input stream. If that is the case then it should be heavily documented with good examples in the wiki to avoid the types of developer anguish we see so regularly. BTW: I'm not at liberty to post the JUnit tests as they use my company's unit test suite framework. Regards, Michael Erskine. From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 06:18:04 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 18:48:04 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Hello Michael, I tried out your suggestion but the problem is that the read(rawbuf) blocks until the entire length of the rawbuf array has been read (blocking). I cannot decide on a reasonable size of the array because it varies from 2 bytes to as much as 50 byes (i'm communicating with a modem,each response is of a different length), which is why i wanted to use non blocking calls. But on a side note, read(byte[]) in turn calls the read() in a loop.In the native C function, the read is supposed to return a -1 upon timeout.But my driver does not support timeout.The default timeout value is zero and the linux select call upon zero time out causes an infinite wait.What am i missing...... Thanks and regards, Ravi Date: Wed, 3 Feb 2010 09:26:50 +0000 From: Michael Erskine To: "rxtx at qbang.org" Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: Content-Type: text/plain; charset="us-ascii" > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From m.kirkland at comcast.net Wed Feb 3 06:46:03 2010 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 3 Feb 2010 05:46:03 -0800 Subject: [Rxtx] One port blocking another port In-Reply-To: References: Message-ID: <68768633814F4D7D86761D34F0764FE0@bengal.net> It turns out this is caused by having the RTS/CTS flow control turned on and me not providing a true on the RTS pin. Somehow it seems the port timing out on a read allows the write to proceed. This is not an issue for my application but I wonder if the write should not proceed until the RTS pin is true even if a read times out. mk -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Monday, January 25, 2010 7:48 PM To: Mike Kirkland Cc: rxtx at qbang.org Subject: Re: [Rxtx] One port blocking another port On Mon, 25 Jan 2010, Mike Kirkland wrote: > > Hi All, > > ? > > I have a program that reads from one com port and writes to another com > port. It also does the same thing in reverse (reads from the second com port > and writes to the first one. It basically ties two com ports together. > > ? > > One port is very chatty and has a consent stream of data. The other port has > very little data. > > ? > > Both ports use a 5000 ms (5 second) time out. > > ? > > The issue I am having is that is appears that the first port?s write to the > second port is blocked while the second port is waiting for input. The first > port?s write proceeds only after the second port has timed out. > > ? > > I suppose I could have something twisted around in my code but I was > wondering if this is a know issue? > Hi Kirk, I've not seen a report like this. Perhaps some simple reproduction code will reveal a problem on your end or help us identify a problem in rxtx. I think there are several users doing multiport communication. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Wed Feb 3 07:03:58 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:03:58 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Message-ID: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> 2010/2/3 Ravishankar N > Hello Michael, > [..] > But on a side note, read(byte[]) in turn calls the read() in a loop.In the > native C function, the read is supposed to return a -1 upon timeout.But my > driver > does not support timeout.The default timeout value is zero and the linux > select call upon zero time out causes an infinite wait.What am i > missing...... > > When I have tested RXTX between platforms, I have observed "hangup" inside JNI driver when no data in Linux, is normal thing. Solution was setting the timeout for RXTX when no data from JNI driver. Something like that: commPort.enableReceiveTimeout(10); And it works perfect.... The only difference is that I am NOT using events - I am using continous read in separate thread and if data is available, is parsed and transferred to application using exception. Regards Mariusz > Thanks and regards, > Ravi > > Date: Wed, 3 Feb 2010 09:26:50 +0000 > From: Michael Erskine > To: "rxtx at qbang.org" > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > Message-ID: > > > Content-Type: text/plain; charset="us-ascii" > > > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of > > Ravishankar N > > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > > > My serial port driver(apparently) does not support receive timeout.I > > registered an event listener for DATA_AVAILABLE. However, the control > never > > seems to come out of the 'while' loop.Shouldn't the > > InputStream.read return a '-1' immediately if no data is available (this > seems > > to be the default operation)? > > Your event handler should handle the event and return immediately so that > its controlling thread can handle other events. I recommend a single read in > the following manner: rawbuf is a byte[] of "reasonable" size and the > read(byte[]) reads all available bytes up to the size of the buffer > returning the number of bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } > > This style of reading has worked for me with RXTX on Linux and Windows XP > for a good few years now in railway industry communications systems. Any > timeouts (largely unnecessary in my applications) can be handled elsewhere, > usually at a higher layer. > > Regards, > Michael Erskine. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Feb 3 07:22:55 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 3 Feb 2010 09:22:55 -0500 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: I'm guessing that this is driver specific. I recently had to support a select()/poll() infrastructure for a linux serial DD, its certainly non trivial to support async IO, so I suspect the problem in this case has to do with missing poll infrastructure in the device driver. This also has to coupled with special open flags for the device (which is within the rxtx code) The key routines within a 2.6 kernel linux device driver are shown below (if you have access to it for your particular device) are indicated below (here is a snippet from my device driver c code that supports polling/select). User space code to test this shown below also, note that the device needs to be opened with the O_NONBLOCK option to support the select/poll api // device driver code ..... /* * File operations supported by this driver. */ static struct file_operations iop_fops = { .owner = THIS_MODULE, .check_flags= iop_check_flags, .ioctl = iop_ioctl, .open = iop_open, .poll = iop_poll, // SUPPORT FOR SELECT/POLL infrastructure .read = iop_read, .release = iop_release, .write = iop_write, }; /** * Select/poll/epoll infrastructure. * * @param file * @param wait * * @return */ static unsigned int iop_poll(struct file *filp, poll_table *wait) { struct iop_device *devp = (struct iop_device *)filp->private_data; // the poll_table wait arg is an opaque pointer poll_wait(filp, &devp->readq, wait); // return from poll indicating whether we have read/write data unsigned int mask = 0; if (kfifo_len(devp->rx_fifo)) { mask |= (POLLIN | POLLRDNORM); } // @JC We don't do select on write yet // if (kfifo_len(devp->tx_fifo)) { // mask |= (POLLOUT | POLLWRNORM); // } // Only print out while debugging // if (mask != 0) { // printk (KERN_INFO "%s: [%04x]\n", __FUNCTION__, mask); // } return mask; } /** * device driver blocking and non blocking read function. This * function reads the requested number of bytes from the read * kfifo blocking as required. * * @param filp * @param buf * @param count * @param f_pos * * @return */ static ssize_t iop_read(struct file *filp, char __user *buf, size_t count, loff_t * ppos) { // access appropriate device struct struct iop_device *devp = (struct iop_device *) filp->private_data; ssize_t retval; // support non blocking mode (default) by checking if the kfifo is empty first if ((kfifo_len(devp->rx_fifo)==0) && (filp->f_flags & O_NONBLOCK)) { return -EAGAIN; } // wait for rx_fifo to receive data via receive interrupts retval = wait_event_interruptible(devp->readq, kfifo_len(devp->rx_fifo) != 0); // check for some error condition if (retval) { printk (KERN_ERR "%s: wait_event_interruptible returned[%d]\n", __FUNCTION__, retval); return retval; } // copy max requested bytes from rx_fifo to device buffer // this may still leave bytes in the kfifo for a subsequent read // if we are reading in a loop retval = kfifo_get(devp->rx_fifo, devp->rxbuf, count); // printk (KERN_INFO "%s: [%d] byte(s)\n", __FUNCTION__, retval); if (copy_to_user(buf, devp->rxbuf, retval)) { printk (KERN_ERR "%s: problem copying rx_fifo data to user buffer\n", __FUNCTION__); return -EFAULT; } return retval; } // a selection of my user space code reading via select()/poll()..... // user space open code iop_fd = ::open( deviceName.data(), O_RDWR | O_NONBLOCK); while ((bytes_to_expect - bytes_read) > 0) { // must reinitialize these between select calls fd_set readfds; FD_ZERO( &readfds ); FD_SET( iop_fd, &readfds ); // 1s sec read polling timeout struct timeval timeout; timeout.tv_sec = 1; timeout.tv_usec = 0; int rc = select( FD_SETSIZE, &readfds, NULL, NULL, &timeout ); // read from file when descriptor // indicates data available without blocking if ((rc > 0) && FD_ISSET(iop_fd, &readfds)) { // read into the appropriate offset within the rx_buf int temp = read(iop_fd, rx_buf + bytes_read, bytes_to_expect - bytes_read); if (!temp) { printf("EOF detected with %d bytes expected\n", bytes_to_expect - bytes_read); } else { bytes_read += temp; } } else if (rc < 0){ printf("%s: select on [%s], bytes_read[%d], errno=%d\n", __FUNCTION__, thread_args->device, bytes_read, errno); } else { printf("%s: select on [%s], bytes_read[%d], timeout\n", __FUNCTION__, thread_args->device, bytes_read); } } On Wed, Feb 3, 2010 at 9:03 AM, Mariusz Dec wrote: > > > 2010/2/3 Ravishankar N > >> Hello Michael, >> [..] >> >> But on a side note, read(byte[]) in turn calls the read() in a loop.In the >> native C function, the read is supposed to return a -1 upon timeout.But my >> driver >> does not support timeout.The default timeout value is zero and the linux >> select call upon zero time out causes an infinite wait.What am i >> missing...... >> >> > When I have tested RXTX between platforms, I have observed "hangup" inside > JNI driver when no data in Linux, is normal thing. > > Solution was setting the timeout for RXTX when no data from JNI driver. > > Something like that: > > commPort.enableReceiveTimeout(10); > > And it works perfect.... > > The only difference is that I am NOT using events - I am using continous > read in separate thread and if data is available, is parsed and transferred > to application using exception. > > Regards > Mariusz > > > >> Thanks and regards, >> Ravi >> >> Date: Wed, 3 Feb 2010 09:26:50 +0000 >> From: Michael Erskine >> To: "rxtx at qbang.org" >> Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? >> Message-ID: >> >> >> Content-Type: text/plain; charset="us-ascii" >> >> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >> Of >> > Ravishankar N >> > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? >> > >> > My serial port driver(apparently) does not support receive timeout.I >> > registered an event listener for DATA_AVAILABLE. However, the control >> never >> > seems to come out of the 'while' loop.Shouldn't the >> > InputStream.read return a '-1' immediately if no data is available (this >> seems >> > to be the default operation)? >> >> Your event handler should handle the event and return immediately so that >> its controlling thread can handle other events. I recommend a single read in >> the following manner: rawbuf is a byte[] of "reasonable" size and the >> read(byte[]) reads all available bytes up to the size of the buffer >> returning the number of bytes actually read... >> >> case SerialPortEvent.DATA_AVAILABLE: >> try { >> int i = is.read(rawbuf); >> if (i == -1) { >> << process EOF condition - should never happen >> >> return; >> } >> << process bytes (rawbuf, i); >> >> return; >> } catch (IOException e) { >> << promptly deal with exception >> >> return; >> } >> >> This style of reading has worked for me with RXTX on Linux and Windows XP >> for a good few years now in railway industry communications systems. Any >> timeouts (largely unnecessary in my applications) can be handled elsewhere, >> usually at a higher layer. >> >> Regards, >> Michael Erskine. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Feb 3 07:33:27 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:33:27 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: <73a89f361002030633j682610afia48dc7accd8e049b@mail.gmail.com> 2010/2/3 John Coffey > I'm guessing that this is driver specific. I recently had to support a > select()/poll() infrastructure for a linux serial DD, its certainly non > trivial to support async IO, so I suspect the problem in this case has to do > with missing poll infrastructure in the device driver. This also has to > coupled with special open flags for the device (which is within the rxtx > code) > > Yes, you are right, it may be driver specific, but in my case I haven't changed blocking JNI driver. I have added ONLY one call to RXTX method mentioned in my previous post and blocking (as seen as from Java app) gone out... Maybe this is not elegant, but works without problem in my app. I am using only FTDI chips and their drivers from couple of years and maybe this is the kind of the way to have no many problems with serial as well? Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From andyrxtx at g0poy.co.uk Wed Feb 3 11:09:04 2010 From: andyrxtx at g0poy.co.uk (andyrxtx at g0poy.co.uk) Date: Wed, 3 Feb 2010 18:09:04 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes Message-ID: <20100203180904.164f24dd@workstation.site> ?Hello RXTX group, I have just joined this group, and this is my first posting. I wanted to pass on some information regarding rxtx, so apologies if this has been brought up before. I have searched back through the archives but nothing specific came up. I am not a Java programmer, and I only came across rxtx a few days ago. I use a piece of test equipment called a miniVNA http://www.miniradiosolutions.com/ This is a serial USB controlled instrument, and it has control software available for MS windows, and a very old and now non-working Linux application. A few days ago Dietmar, DL2SBA released a Java application to control the miniVNA, obviously this application makes use of rxtx. The program worked fine on Windows, so I set about installing it onto Linux. I use SUSE11.1 After a few false starts, I got the system running fairly easily, sorting out the file locking by adding the uucp group to the users account as suggested (I used the 2.2pre binary files) I then passed the install instructions onto another miniVNA user, who also uses SUSE, but he ran into problems. To cut a long story short, he was also having file lock problems, but the uucp fix did not work. Digging into his system I found that there have been some changes in SUSE 11.2. tty ports are now assigned to the dialout group rather than uucp. A hint in the rxtx INSTALL file, suggested that var/lock needs to be checked, so: SUSE 11.1, var/lock is root:uucp SUSE 11.2 var/lock is root:root A search on Google brought up several comments regarding this, and also a bugzilla entry. https://bugzilla.novell.com/show_bug.cgi?id=552095 However from reading the various posts, some of which are in the bugzilla entry, it appears that many distros may be, or have changed to this configuration, and this will undoubtedly break several things, rxtx included. I solved my fellow SUSE users problem by compiling the rxtx libs with the no lock file option during configure, and that solved his problem. As this issue will probably take some time to get resolved across all the various Linux distros, it might be worth considering changing the default on the Linux build of rxtx not to use lockfiles, or provide the two versions of the lib in the binary archive. Thanks for your indulgence Andy From damorales at gmail.com Wed Feb 3 11:33:23 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 15:33:23 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203180904.164f24dd@workstation.site> References: <20100203180904.164f24dd@workstation.site> Message-ID: Hi I had the same problem in Mandriva 2010 and yes, adding the user to the uucp group did not work as it used to be in earlier versions of linux distros, causing RXTX to not work as non root user. The problem appears because the existense of UDEV, now you MUST add a RULE so the group (uucp or whatever) have access (Read, Write, Execute) to the Serial Port. To solve the problem, without needing to recompile RXTX, you must add a rule to grant permissions (0666) to the group for the device or port (tty*, ttyUSB*, etc). I do not remember now what is the line i added but when i come back home i will give it to you (i am at work now). Greetings ! 2010/2/3 > Hello RXTX group, > > I have just joined this group, and this is my first posting. > I wanted to pass on some information regarding rxtx, so apologies if > this has been brought up before. I have searched back through the > archives but nothing specific came up. > > I am not a Java programmer, and I only came across rxtx a few days ago. > > I use a piece of test equipment called a miniVNA > http://www.miniradiosolutions.com/ > > This is a serial USB controlled instrument, and it has control software > available for MS windows, and a very old and now non-working Linux > application. > > A few days ago Dietmar, DL2SBA released a Java application to control the > miniVNA, obviously this application makes use of rxtx. > > The program worked fine on Windows, so I set about installing it onto > Linux. I use SUSE11.1 After a few false starts, I got the system running > fairly easily, sorting out the file locking by adding the uucp group to > the users account as suggested (I used the 2.2pre binary files) I then > passed the install instructions onto another miniVNA user, who also uses > SUSE, but he ran into problems. To cut a long story short, he was > also having file lock problems, but the uucp fix did not work. Digging > into his system I found that there have been some changes in SUSE 11.2. > > tty ports are now assigned to the dialout group rather than uucp. > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > checked, so: > > SUSE 11.1, var/lock is root:uucp > SUSE 11.2 var/lock is root:root > > A search on Google brought up several comments regarding this, and also > a bugzilla entry. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > However from reading the various posts, some of which are in the bugzilla > entry, it appears that many distros may be, or have changed to this > configuration, and this will undoubtedly break several things, rxtx > included. > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > no lock file option during configure, and that solved his problem. > > As this issue will probably take some time to get resolved across all the > various Linux distros, it might be worth considering changing the default > on the Linux build of rxtx not to use lockfiles, or provide the two > versions of the lib in the binary archive. > > Thanks for your indulgence > > Andy > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Wed Feb 3 12:07:02 2010 From: andy at g0poy.com (Andy Eskelson) Date: Wed, 3 Feb 2010 19:07:02 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> Message-ID: <20100203190702.1b0e7015@workstation.site> Thanks Daniel, I am aware of the permissions problem, I have had a udev rules to solve this for other programs for some time. . I don't think that this is the same problem. as far as I can understand things, the lock files are written in var/lock. Previously var/lock and dev/tty-whatever were the same group. Now with var/lock owned by and with a group of root:root anything other than root cannot create a lock file. Even minicom is broken by this change. This change is going to have quite a few knock-on effects I think. Andy On Wed, 3 Feb 2010 15:33:23 -0300 Daniel Morales Salas wrote: > Hi > > I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > group did not work as it used to be in earlier versions of linux distros, > causing RXTX to not work as non root user. > > The problem appears because the existense of UDEV, now you MUST add a RULE > so the group (uucp or whatever) have access (Read, Write, Execute) to the > Serial Port. > > To solve the problem, without needing to recompile RXTX, you must add a rule > to grant permissions (0666) to the group for the device or port (tty*, > ttyUSB*, etc). I do not remember now what is the line i added but when i > come back home i will give it to you (i am at work now). > > Greetings ! > > 2010/2/3 > > > Hello RXTX group, > > > > I have just joined this group, and this is my first posting. > > I wanted to pass on some information regarding rxtx, so apologies if > > this has been brought up before. I have searched back through the > > archives but nothing specific came up. > > > > I am not a Java programmer, and I only came across rxtx a few days ago. > > > > I use a piece of test equipment called a miniVNA > > http://www.miniradiosolutions.com/ > > > > This is a serial USB controlled instrument, and it has control software > > available for MS windows, and a very old and now non-working Linux > > application. > > > > A few days ago Dietmar, DL2SBA released a Java application to control the > > miniVNA, obviously this application makes use of rxtx. > > > > The program worked fine on Windows, so I set about installing it onto > > Linux. I use SUSE11.1 After a few false starts, I got the system running > > fairly easily, sorting out the file locking by adding the uucp group to > > the users account as suggested (I used the 2.2pre binary files) I then > > passed the install instructions onto another miniVNA user, who also uses > > SUSE, but he ran into problems. To cut a long story short, he was > > also having file lock problems, but the uucp fix did not work. Digging > > into his system I found that there have been some changes in SUSE 11.2. > > > > tty ports are now assigned to the dialout group rather than uucp. > > > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > checked, so: > > > > SUSE 11.1, var/lock is root:uucp > > SUSE 11.2 var/lock is root:root > > > > A search on Google brought up several comments regarding this, and also > > a bugzilla entry. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > However from reading the various posts, some of which are in the bugzilla > > entry, it appears that many distros may be, or have changed to this > > configuration, and this will undoubtedly break several things, rxtx > > included. > > > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > > no lock file option during configure, and that solved his problem. > > > > As this issue will probably take some time to get resolved across all the > > various Linux distros, it might be worth considering changing the default > > on the Linux build of rxtx not to use lockfiles, or provide the two > > versions of the lib in the binary archive. > > > > Thanks for your indulgence > > > > Andy > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From thisdyingdream at gmail.com Wed Feb 3 12:32:35 2010 From: thisdyingdream at gmail.com (Steven Harms) Date: Wed, 3 Feb 2010 14:32:35 -0500 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203190702.1b0e7015@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: This is currently a bug in OpenSUSE that affects more than just rxtx, and is a result of unified udev rules. You can work around this by making udev change the group back to uucp until something more happens. https://bugzilla.novell.com/show_bug.cgi?id=552095 Thanks, Steve On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > Thanks Daniel, > > I am aware of the permissions problem, I have had a udev rules to solve > this for other programs for some time. > . > I don't think that this is the same problem. as far as I can understand > things, the lock files are written in var/lock. Previously var/lock and > dev/tty-whatever were the same group. Now with var/lock owned by and with > a group of root:root anything other than root cannot create a lock > file. Even minicom is broken by this change. > > This change is going to have quite a few knock-on effects I think. > > > Andy > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > Daniel Morales Salas wrote: > >> Hi >> >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp >> group did not work as it used to be in earlier versions of linux distros, >> causing RXTX to not work as non root user. >> >> The problem appears because the existense of UDEV, now you MUST add a RULE >> so the group (uucp or whatever) have access (Read, Write, Execute) to the >> Serial Port. >> >> To solve the problem, without needing to recompile RXTX, you must add a rule >> to grant permissions (0666) to the group for the device or port (tty*, >> ttyUSB*, etc). I do not remember now what is the line i added but when i >> come back home i will give it to you (i am at work now). >> >> Greetings ! >> >> 2010/2/3 >> >> > Hello RXTX group, >> > >> > I have just joined this group, and this is my first posting. >> > I wanted to pass on ?some information regarding rxtx, so apologies if >> > this has been brought up before. I have searched back through the >> > archives but nothing specific came up. >> > >> > I am not a Java programmer, and I only came across rxtx a few days ago. >> > >> > I use a piece of test equipment called a miniVNA >> > http://www.miniradiosolutions.com/ >> > >> > This is a serial USB controlled instrument, and it has control software >> > available for MS windows, and a very old and now non-working Linux >> > application. >> > >> > A few days ago Dietmar, DL2SBA released a Java application to control the >> > miniVNA, obviously this application makes use of rxtx. >> > >> > The program worked fine on Windows, so I set about installing it onto >> > Linux. I use SUSE11.1 After a few false starts, I got the system running >> > fairly easily, sorting out the file locking by adding the uucp group to >> > the users account as suggested (I used the 2.2pre binary files) I then >> > passed the install instructions onto another miniVNA user, who also uses >> > SUSE, but he ran into problems. To cut a long story short, he was >> > also having file lock problems, but the uucp fix did not work. Digging >> > into his system I found that there have been some changes in SUSE 11.2. >> > >> > tty ports are now assigned to the dialout group rather than uucp. >> > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be >> > checked, so: >> > >> > SUSE 11.1, var/lock is root:uucp >> > SUSE 11.2 var/lock is root:root >> > >> > A search on Google brought up several comments regarding this, and also >> > a ?bugzilla entry. >> > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 >> > >> > However from reading the various posts, some of which are in the bugzilla >> > entry, it appears that many distros may be, or have changed to this >> > configuration, and this will undoubtedly break several things, rxtx >> > included. >> > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the >> > no lock file option during configure, and that solved his problem. >> > >> > As this issue will probably take some time to get resolved across all the >> > various Linux distros, it might be worth considering changing the default >> > on the Linux build of rxtx not to use lockfiles, or provide the two >> > versions of the lib in the binary archive. >> > >> > Thanks for your indulgence >> > >> > Andy >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> >> >> >> -- >> Atte: >> Daniel Dario Morales Salas >> Ingeniero Civil en Computaci?n e Inform?tica >> Tel?fono: 02 684 3417 >> Celular: 09 643 1802 >> Santiago, Chile > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 WWW: http://www.sharms.org/blog From andy at g0poy.com Wed Feb 3 17:58:29 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 00:58:29 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: <20100204005829.7dc944e1@workstation.site> Thanks Steve, changing the serial ports back the uucp is not a big problem. I have a udev rule that can be easily modified already. However I cannot see any way of dealing with the var/lock problem apart from making it writable to all. Any thoughts? Andy On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms wrote: > This is currently a bug in OpenSUSE that affects more than just rxtx, > and is a result of unified udev rules. You can work around this by > making udev change the group back to uucp until something more > happens. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > Thanks, > > Steve > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > Thanks Daniel, > > > > I am aware of the permissions problem, I have had a udev rules to solve > > this for other programs for some time. > > . > > I don't think that this is the same problem. as far as I can understand > > things, the lock files are written in var/lock. Previously var/lock and > > dev/tty-whatever were the same group. Now with var/lock owned by and with > > a group of root:root anything other than root cannot create a lock > > file. Even minicom is broken by this change. > > > > This change is going to have quite a few knock-on effects I think. > > > > > > Andy > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > Daniel Morales Salas wrote: > > > >> Hi > >> > >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > >> group did not work as it used to be in earlier versions of linux distros, > >> causing RXTX to not work as non root user. > >> > >> The problem appears because the existense of UDEV, now you MUST add a RULE > >> so the group (uucp or whatever) have access (Read, Write, Execute) to the > >> Serial Port. > >> > >> To solve the problem, without needing to recompile RXTX, you must add a rule > >> to grant permissions (0666) to the group for the device or port (tty*, > >> ttyUSB*, etc). I do not remember now what is the line i added but when i > >> come back home i will give it to you (i am at work now). > >> > >> Greetings ! > >> > >> 2010/2/3 > >> > >> > Hello RXTX group, > >> > > >> > I have just joined this group, and this is my first posting. > >> > I wanted to pass on ?some information regarding rxtx, so apologies if > >> > this has been brought up before. I have searched back through the > >> > archives but nothing specific came up. > >> > > >> > I am not a Java programmer, and I only came across rxtx a few days ago. > >> > > >> > I use a piece of test equipment called a miniVNA > >> > http://www.miniradiosolutions.com/ > >> > > >> > This is a serial USB controlled instrument, and it has control software > >> > available for MS windows, and a very old and now non-working Linux > >> > application. > >> > > >> > A few days ago Dietmar, DL2SBA released a Java application to control the > >> > miniVNA, obviously this application makes use of rxtx. > >> > > >> > The program worked fine on Windows, so I set about installing it onto > >> > Linux. I use SUSE11.1 After a few false starts, I got the system running > >> > fairly easily, sorting out the file locking by adding the uucp group to > >> > the users account as suggested (I used the 2.2pre binary files) I then > >> > passed the install instructions onto another miniVNA user, who also uses > >> > SUSE, but he ran into problems. To cut a long story short, he was > >> > also having file lock problems, but the uucp fix did not work. Digging > >> > into his system I found that there have been some changes in SUSE 11.2. > >> > > >> > tty ports are now assigned to the dialout group rather than uucp. > >> > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > >> > checked, so: > >> > > >> > SUSE 11.1, var/lock is root:uucp > >> > SUSE 11.2 var/lock is root:root > >> > > >> > A search on Google brought up several comments regarding this, and also > >> > a ?bugzilla entry. > >> > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > >> > > >> > However from reading the various posts, some of which are in the bugzilla > >> > entry, it appears that many distros may be, or have changed to this > >> > configuration, and this will undoubtedly break several things, rxtx > >> > included. > >> > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the > >> > no lock file option during configure, and that solved his problem. > >> > > >> > As this issue will probably take some time to get resolved across all the > >> > various Linux distros, it might be worth considering changing the default > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > >> > versions of the lib in the binary archive. > >> > > >> > Thanks for your indulgence > >> > > >> > Andy > >> > > >> > _______________________________________________ > >> > Rxtx mailing list > >> > Rxtx at qbang.org > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > >> > >> > >> > >> -- > >> Atte: > >> Daniel Dario Morales Salas > >> Ingeniero Civil en Computaci?n e Inform?tica > >> Tel?fono: 02 684 3417 > >> Celular: 09 643 1802 > >> Santiago, Chile > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > WWW: http://www.sharms.org/blog From damorales at gmail.com Wed Feb 3 18:26:38 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 22:26:38 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100204005829.7dc944e1@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: Hello I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva 2010 this is what i get: drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ and i don't have ANY problem with lock files and RXTX in my java software. All i had to do was add this rule to udev: # serial KERNEL=="tty*", GROUP="uucp", MODE="0666" and that was all. Of course my user (metalklesk) is part of uucp group. I did not make /var/lock writable to all users. Greetings ! 2010/2/3 Andy Eskelson > Thanks Steve, > > changing the serial ports back the uucp is not a big problem. I have a > udev rule that can be easily modified already. However I cannot see any > way of dealing with the var/lock problem apart from making it writable to > all. Any thoughts? > > Andy > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > wrote: > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > and is a result of unified udev rules. You can work around this by > > making udev change the group back to uucp until something more > > happens. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > Thanks, > > > > Steve > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > Thanks Daniel, > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > this for other programs for some time. > > > . > > > I don't think that this is the same problem. as far as I can understand > > > things, the lock files are written in var/lock. Previously var/lock and > > > dev/tty-whatever were the same group. Now with var/lock owned by and > with > > > a group of root:root anything other than root cannot create a lock > > > file. Even minicom is broken by this change. > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > Daniel Morales Salas wrote: > > > > > >> Hi > > >> > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > the uucp > > >> group did not work as it used to be in earlier versions of linux > distros, > > >> causing RXTX to not work as non root user. > > >> > > >> The problem appears because the existense of UDEV, now you MUST add a > RULE > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > the > > >> Serial Port. > > >> > > >> To solve the problem, without needing to recompile RXTX, you must add > a rule > > >> to grant permissions (0666) to the group for the device or port (tty*, > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > i > > >> come back home i will give it to you (i am at work now). > > >> > > >> Greetings ! > > >> > > >> 2010/2/3 > > >> > > >> > Hello RXTX group, > > >> > > > >> > I have just joined this group, and this is my first posting. > > >> > I wanted to pass on some information regarding rxtx, so apologies > if > > >> > this has been brought up before. I have searched back through the > > >> > archives but nothing specific came up. > > >> > > > >> > I am not a Java programmer, and I only came across rxtx a few days > ago. > > >> > > > >> > I use a piece of test equipment called a miniVNA > > >> > http://www.miniradiosolutions.com/ > > >> > > > >> > This is a serial USB controlled instrument, and it has control > software > > >> > available for MS windows, and a very old and now non-working Linux > > >> > application. > > >> > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > control the > > >> > miniVNA, obviously this application makes use of rxtx. > > >> > > > >> > The program worked fine on Windows, so I set about installing it > onto > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > running > > >> > fairly easily, sorting out the file locking by adding the uucp group > to > > >> > the users account as suggested (I used the 2.2pre binary files) I > then > > >> > passed the install instructions onto another miniVNA user, who also > uses > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > >> > also having file lock problems, but the uucp fix did not work. > Digging > > >> > into his system I found that there have been some changes in SUSE > 11.2. > > >> > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > >> > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > >> > checked, so: > > >> > > > >> > SUSE 11.1, var/lock is root:uucp > > >> > SUSE 11.2 var/lock is root:root > > >> > > > >> > A search on Google brought up several comments regarding this, and > also > > >> > a bugzilla entry. > > >> > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > >> > > > >> > However from reading the various posts, some of which are in the > bugzilla > > >> > entry, it appears that many distros may be, or have changed to this > > >> > configuration, and this will undoubtedly break several things, rxtx > > >> > included. > > >> > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > with the > > >> > no lock file option during configure, and that solved his problem. > > >> > > > >> > As this issue will probably take some time to get resolved across > all the > > >> > various Linux distros, it might be worth considering changing the > default > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > >> > versions of the lib in the binary archive. > > >> > > > >> > Thanks for your indulgence > > >> > > > >> > Andy > > >> > > > >> > _______________________________________________ > > >> > Rxtx mailing list > > >> > Rxtx at qbang.org > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > >> > > > >> > > >> > > >> > > >> -- > > >> Atte: > > >> Daniel Dario Morales Salas > > >> Ingeniero Civil en Computaci?n e Inform?tica > > >> Tel?fono: 02 684 3417 > > >> Celular: 09 643 1802 > > >> Santiago, Chile > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at qbang.org > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > -- > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > WWW: http://www.sharms.org/blog > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Thu Feb 4 05:31:46 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 12:31:46 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: <20100204123146.6cffeb67@workstation.site> Thank's for the confirmation. Something odd is going on somewhere in SUSE 11.2. I'll have to build up a local SUSE11.2 system to see if I can nail down exactly what is going on. Something is blocking the lockfiles in var/lock. The net is nice, but it's a bit difficult trying to work out what is going on what the machine in question is in Germany and I'm in the UK :-) Andy On Wed, 3 Feb 2010 22:26:38 -0300 Daniel Morales Salas wrote: > Hello > > I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva > 2010 this is what i get: > > drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ > > and i don't have ANY problem with lock files and RXTX in my java software. > All i had to do was add this rule to udev: > > # serial > KERNEL=="tty*", GROUP="uucp", MODE="0666" > > and that was all. Of course my user (metalklesk) is part of uucp group. > I did not make /var/lock writable to all users. > > Greetings ! > > 2010/2/3 Andy Eskelson > > > Thanks Steve, > > > > changing the serial ports back the uucp is not a big problem. I have a > > udev rule that can be easily modified already. However I cannot see any > > way of dealing with the var/lock problem apart from making it writable to > > all. Any thoughts? > > > > Andy > > > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > > wrote: > > > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > > and is a result of unified udev rules. You can work around this by > > > making udev change the group back to uucp until something more > > > happens. > > > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > > > Thanks, > > > > > > Steve > > > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > > Thanks Daniel, > > > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > > this for other programs for some time. > > > > . > > > > I don't think that this is the same problem. as far as I can understand > > > > things, the lock files are written in var/lock. Previously var/lock and > > > > dev/tty-whatever were the same group. Now with var/lock owned by and > > with > > > > a group of root:root anything other than root cannot create a lock > > > > file. Even minicom is broken by this change. > > > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > > Daniel Morales Salas wrote: > > > > > > > >> Hi > > > >> > > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > > the uucp > > > >> group did not work as it used to be in earlier versions of linux > > distros, > > > >> causing RXTX to not work as non root user. > > > >> > > > >> The problem appears because the existense of UDEV, now you MUST add a > > RULE > > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > > the > > > >> Serial Port. > > > >> > > > >> To solve the problem, without needing to recompile RXTX, you must add > > a rule > > > >> to grant permissions (0666) to the group for the device or port (tty*, > > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > > i > > > >> come back home i will give it to you (i am at work now). > > > >> > > > >> Greetings ! > > > >> > > > >> 2010/2/3 > > > >> > > > >> > Hello RXTX group, > > > >> > > > > >> > I have just joined this group, and this is my first posting. > > > >> > I wanted to pass on some information regarding rxtx, so apologies > > if > > > >> > this has been brought up before. I have searched back through the > > > >> > archives but nothing specific came up. > > > >> > > > > >> > I am not a Java programmer, and I only came across rxtx a few days > > ago. > > > >> > > > > >> > I use a piece of test equipment called a miniVNA > > > >> > http://www.miniradiosolutions.com/ > > > >> > > > > >> > This is a serial USB controlled instrument, and it has control > > software > > > >> > available for MS windows, and a very old and now non-working Linux > > > >> > application. > > > >> > > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > > control the > > > >> > miniVNA, obviously this application makes use of rxtx. > > > >> > > > > >> > The program worked fine on Windows, so I set about installing it > > onto > > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > > running > > > >> > fairly easily, sorting out the file locking by adding the uucp group > > to > > > >> > the users account as suggested (I used the 2.2pre binary files) I > > then > > > >> > passed the install instructions onto another miniVNA user, who also > > uses > > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > > >> > also having file lock problems, but the uucp fix did not work. > > Digging > > > >> > into his system I found that there have been some changes in SUSE > > 11.2. > > > >> > > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > > >> > > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > > >> > checked, so: > > > >> > > > > >> > SUSE 11.1, var/lock is root:uucp > > > >> > SUSE 11.2 var/lock is root:root > > > >> > > > > >> > A search on Google brought up several comments regarding this, and > > also > > > >> > a bugzilla entry. > > > >> > > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > >> > > > > >> > However from reading the various posts, some of which are in the > > bugzilla > > > >> > entry, it appears that many distros may be, or have changed to this > > > >> > configuration, and this will undoubtedly break several things, rxtx > > > >> > included. > > > >> > > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > > with the > > > >> > no lock file option during configure, and that solved his problem. > > > >> > > > > >> > As this issue will probably take some time to get resolved across > > all the > > > >> > various Linux distros, it might be worth considering changing the > > default > > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > > >> > versions of the lib in the binary archive. > > > >> > > > > >> > Thanks for your indulgence > > > >> > > > > >> > Andy > > > >> > > > > >> > _______________________________________________ > > > >> > Rxtx mailing list > > > >> > Rxtx at qbang.org > > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > > >> > > > > >> > > > >> > > > >> > > > >> -- > > > >> Atte: > > > >> Daniel Dario Morales Salas > > > >> Ingeniero Civil en Computaci?n e Inform?tica > > > >> Tel?fono: 02 684 3417 > > > >> Celular: 09 643 1802 > > > >> Santiago, Chile > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at qbang.org > > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > > > -- > > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > > > WWW: http://www.sharms.org/blog > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From Bob_Jacobsen at lbl.gov Thu Feb 4 09:26:49 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Thu, 4 Feb 2010 08:26:49 -0800 Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 Message-ID: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're using RXTX-2.2pre2, although it emits the known message about "Version mismatch". WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 After the usual messing around, we've got it working on 11 Windows versions, multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ have things working rarely say so, so I don't know whether anybody has gotten it to work on 10.4 or not. The problem encountered is this: dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib dyld: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib followed by the JVM crashing hard. I've got those dump files if that would help. Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If so, is there a patch I can get and build? Thanks Bob -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From tjarvi at qbang.org Thu Feb 4 14:22:21 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 4 Feb 2010 14:22:21 -0700 (MST) Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 In-Reply-To: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> References: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> Message-ID: On Thu, 4 Feb 2010, Bob Jacobsen wrote: > We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're > using RXTX-2.2pre2, although it emits the known message about "Version > mismatch". > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > > After the usual messing around, we've got it working on 11 Windows versions, > multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with > a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ > have things working rarely say so, so I don't know whether anybody has gotten > it to work on 10.4 or not. > > The problem encountered is this: > > dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > dyld: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > followed by the JVM crashing hard. I've got those dump files if that would > help. > > Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If > so, is there a patch I can get and build? > Hi Bob, I talked to a coworker about the problem you ran into. It appears that it is possible to target 'older' Mac systems through makefile configuration changes. "Configuring a Makefile-Based Project If you have a makefile-based project, you can also take advantage of SDK-based development, by adding the appropriate options to your compile and link commands. Using SDKs in makefile-based projects requires GCC 4.0 or later. To choose an SDK, you use the -isysroot option with the compiler and the -syslibroot option with the linker. Both options require that you specify the full path to the desired SDK directory. To set the Deployment OS version in a makefile, use a makefile variable of the form: ENVP= MACOSX_DEPLOYMENT_TARGET=10.4. To use this variable in your makefile, include it in front of your compile and link commands." http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html Or build on the oldest system you want to support. -- Trent Jarvi tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Thu Feb 4 14:56:19 2010 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Thu, 4 Feb 2010 14:56:19 -0700 Subject: [Rxtx] RXTX on 64 Bit Redhat In-Reply-To: References: <4ec9eab61001281448g3dd84910r867619948a4e0d7a@mail.gmail.com> Message-ID: Trent -- Finally fixed all my build related issues. I ran into another issue. On one of my machines my JDK is returning multiple folders for the "java.ext.dirs" (java.ext.dirs -> /opt/jdk1.6.0_17/jre/lib/ext:/usr/java/packages/lib/ext) system property. As a result my JVM wasn't able to detect the gnu.io.rxtx.properties. I am attaching a patch for RXTXCommDriver.java file to check for multiple locations. Also i have to assign permission 660 to all my dev ports to be located by RXTX. Pawan ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 5:12 PM To: Trent Jarvi Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Here is the error i get when i build the src from release-2-1-7 -bash-3.2$ make ( \ \ cd i686-pc-linux-gnu; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/ jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I/opt/jav a1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec - c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialImp.lo;\ if [ "Serial" = "Serial" ]; then \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I /opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_tim espec -c /home/jb_stg/rxtx/rxtx-devel/./src/fuserImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ else \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo; \ fi; \ ) gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/inclu de -I/opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need _timespec -c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -fPIC -DPIC -o /hom e/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/.libs/SerialImp.o /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:25:29: error: gnu_io_RXTXPort.h: No such file or directory In file included from /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:113: /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:91: error: expected specifier-qua lifier-list before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'jobject' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:408: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:409: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:410: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:411: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:415: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:416: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:417: error: expected '=', ',', '; ', 'asm' or '__attribute__' before 'is_interrupted' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:418: error: expected declaration specifiers or '...' before 'jint' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:424: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:441: error: expected ')' before ' *' token ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 4:57 PM To: Santosh Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Santosh -- Thank you. That fixed the issue. All -- What CVS branch or release should i use to get the latest RXTX src code. Pawan ________________________________ From: Santosh [mailto:santosh.ry at gmail.com] Sent: Thursday, January 28, 2010 3:49 PM To: Kharbanda, Pawan Cc: Trent Jarvi; rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat error "./configure: /bin/sh^M: bad interpreter: No such file or directory". I think you need to run dos2unix on script files before compiling. Thanks, Santosh On Thu, Jan 28, 2010 at 5:33 PM, Kharbanda, Pawan > wrote: Trent -- We are upgrading our exisiting OS and JDK on a project that rely heavily on RXTX api's. We are now using JDK1.6 32 bit (build 1.6.0_17-b04) and RedHat 5 on a 64 bit machine. Linux tocrhstg02.dot.state.co.us 2.6.18-164.6.1.el5 #1 SMP Tue Oct 27 11:30:06 EDT 2009 i686 i686 i386 GNU/Linux Red Hat Enterprise Linux Server release 5.4 (Tikanga) I tried to run version 2.1.7 r2 on it but not able to see any of my Digi ports I was able to access only /dev/ttyS0 (physical ports). Not sure if the problem is with the Digi driver or RXTX. I tried to open a Digi port with minicom and it worked fine. I also tried to get latest from CVS (rxtx-devel) and when I do "configure" I see this error "./configure: /bin/sh^M: bad interpreter: No such file or directory". Can someone please help me with this? Thanks for the help. Pawan _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch.txt URL: From juan.vicente.l.g at gmail.com Sat Feb 13 04:44:17 2010 From: juan.vicente.l.g at gmail.com (Juan Vicente Lopez Gutierrez) Date: Sat, 13 Feb 2010 12:44:17 +0100 Subject: [Rxtx] RXTX in macmini OSX 10.5 Message-ID: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> Hello. My name is Juanvi and I'm from Spain. I tried to launch a software created by me in the library CXR java to send information through the serial port and I can not make it work. In windows if I've done but not mac. I have a mac mini with OSX 10.5 and have read in the list of web mail that you CXR if you have managed to make it work on that operating system. I need you help me please. Do I make the mistake that shows me java: run: Stable Library =============================== Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 gnu.io.PortInUseException: Unknow Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:26) at TwoWatSerialComm.main(TwoWaySerialComm.java:106) Experimental: JNI_OnLoad called. GENERACION CORRECTA (total time: 0 seconds) I do not have permission to access the serial port, do not know. Os agradeceria much to sit down. A greeting and thanks. Pardon my English. Juanvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From juan.vicente.l.g at gmail.com Sat Feb 13 14:39:41 2010 From: juan.vicente.l.g at gmail.com (Juan Vicente Lopez Gutierrez) Date: Sat, 13 Feb 2010 22:39:41 +0100 Subject: [Rxtx] Fwd: RXTX in macmini OSX 10.5 In-Reply-To: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> References: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> Message-ID: <29405e5c1002131339m2059d169sdc8549ed9706a1af@mail.gmail.com> ---------- Forwarded message ---------- From: Juan Vicente Lopez Gutierrez Date: 2010/2/13 Subject: RXTX in macmini OSX 10.5 To: rxtx at qbang.org Hello. My name is Juanvi and I'm from Spain. I tried to launch a software created by me in the library CXR java to send information through the serial port and I can not make it work. In windows if I've done but not mac. I have a mac mini with OSX 10.5 and have read in the list of web mail that you CXR if you have managed to make it work on that operating system. I need you help me please. Do I make the mistake that shows me java: run: Stable Library =============================== Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 gnu.io.PortInUseException: Unknow Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:26) at TwoWatSerialComm.main(TwoWaySerialComm.java:106) Experimental: JNI_OnLoad called. GENERACION CORRECTA (total time: 0 seconds) I do not have permission to access the serial port, do not know. Os agradeceria much to sit down. A greeting and thanks. Pardon my English. Juanvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Mon Feb 22 04:35:48 2010 From: george.dma at gmail.com (George H) Date: Mon, 22 Feb 2010 13:35:48 +0200 Subject: [Rxtx] Lingering rxtx process Message-ID: Hi, I am using RXTX v2.1-7. I use it to communicate with 2 serial receipt printers and 1 serial line display device. My program runs well using the RXTX library on Windows and Linux. But... when I installed Linux on another hardware the program does not exit properly. By this I mean that the java program seems to have exited (passed the System.exit(0)) code but the console still does not return to the bash shell. I have to CTRL+C each time to kill the program. And on each restart RXTX has to remove stale LCK files. Just note I am only getting this on one machine, if it makes any difference it is an i686 system with all VIA chipsets and VIA-C7M NannoBGA2 processor. Any ideas? Thanks -- George H george.dma at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Mon Feb 22 04:43:43 2010 From: george.dma at gmail.com (George H) Date: Mon, 22 Feb 2010 13:43:43 +0200 Subject: [Rxtx] Lingering rxtx process Message-ID: Hi, I am using RXTX v2.1-7. I use it to communicate with 2 serial receipt printers and 1 serial line display device. My program runs well using the RXTX library on Windows and Linux. But... when I installed Linux on another hardware the program does not exit properly. By this I mean that the java program seems to have exited (passed the System.exit(0)) code but the console still does not return to the bash shell. I have to CTRL+C each time to kill the program. And on each restart RXTX has to remove stale LCK files. Just note I am only getting this on one machine, if it makes any difference it is an i686 system with all VIA chipsets and VIA-C7M NannoBGA2 processor. Any ideas? Thanks -- George H george.dma at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 01:02:21 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 13:32:21 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> My serial port driver(apparently) does not support receive timeout.I registered an event listener for DATA_AVAILABLE. However, the control never seems to come out of the 'while' loop.Shouldn't the InputStream.read return a '-1' immediately if no data is available (this seems to be the default operation)? This was tried on a x86 Linux desktop using rxtx-2.1-7 I've added the snippet for clarity: /******************************************************************************************************************************************************************************/ mySerialPort.enableReceiveThreshold(2000);//Trying to set a time limit for read calls System.out.println(mySerialPort.isReceiveTimeoutEnabled()); // I get FALSE, so its not supported on hardware. mySerialPort.addEventListener(this); mySerialPort.notifyOnDataAvailable(true);//register a event with //my SerialEvent listener implementation: public void serialEvent(SerialPortEvent arg0) { int newData=0; switch(arg0.getEventType()){ case SerialPortEvent.DATA_AVAILABLE: while (newData != -1) { try { newData = is.read();//This should eventually return a -1 if no data is available within a timeout.PROBLEM!! System.out.println("Got a byte from port:"+newData); if (newData == -1) { break; } } catch (IOException ex) { System.err.println(ex); return; } } break; } return; } /******************************************************************************************************************************************************************************/ Thanks and regards, Ravi From michael.erskine at ketech.com Wed Feb 3 02:26:50 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 09:26:50 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From michael.erskine at ketech.com Wed Feb 3 05:03:30 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 12:03:30 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > Michael Erskine > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > > Your event handler should handle the event and return immediately so that its > controlling thread can handle other events. I recommend a single read in the > following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) > reads all available bytes up to the size of the buffer returning the number of > bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } After posting this I considered the glaring possibility of the rawbuf read buffer being too small to receive all the available bytes and perhaps skipping data: after all, I'm guessing that is why we see so many posts asking for help with blocking implementations of read event handlers looping on "while(bytes are available)". I've spent this morning writing an extensive multi-threaded unit test suite that includes tests with a tiny buffer compared to the amount of data available and found that no data was being skipped. I now want to know why! The SerialPortEvent.DATA_AVAILABLE event must be being fired again if there is more data available on the input stream. If that is the case then it should be heavily documented with good examples in the wiki to avoid the types of developer anguish we see so regularly. BTW: I'm not at liberty to post the JUnit tests as they use my company's unit test suite framework. Regards, Michael Erskine. From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 06:18:04 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 18:48:04 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Hello Michael, I tried out your suggestion but the problem is that the read(rawbuf) blocks until the entire length of the rawbuf array has been read (blocking). I cannot decide on a reasonable size of the array because it varies from 2 bytes to as much as 50 byes (i'm communicating with a modem,each response is of a different length), which is why i wanted to use non blocking calls. But on a side note, read(byte[]) in turn calls the read() in a loop.In the native C function, the read is supposed to return a -1 upon timeout.But my driver does not support timeout.The default timeout value is zero and the linux select call upon zero time out causes an infinite wait.What am i missing...... Thanks and regards, Ravi Date: Wed, 3 Feb 2010 09:26:50 +0000 From: Michael Erskine To: "rxtx at qbang.org" Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: Content-Type: text/plain; charset="us-ascii" > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From m.kirkland at comcast.net Wed Feb 3 06:46:03 2010 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 3 Feb 2010 05:46:03 -0800 Subject: [Rxtx] One port blocking another port In-Reply-To: References: Message-ID: <68768633814F4D7D86761D34F0764FE0@bengal.net> It turns out this is caused by having the RTS/CTS flow control turned on and me not providing a true on the RTS pin. Somehow it seems the port timing out on a read allows the write to proceed. This is not an issue for my application but I wonder if the write should not proceed until the RTS pin is true even if a read times out. mk -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Monday, January 25, 2010 7:48 PM To: Mike Kirkland Cc: rxtx at qbang.org Subject: Re: [Rxtx] One port blocking another port On Mon, 25 Jan 2010, Mike Kirkland wrote: > > Hi All, > > ? > > I have a program that reads from one com port and writes to another com > port. It also does the same thing in reverse (reads from the second com port > and writes to the first one. It basically ties two com ports together. > > ? > > One port is very chatty and has a consent stream of data. The other port has > very little data. > > ? > > Both ports use a 5000 ms (5 second) time out. > > ? > > The issue I am having is that is appears that the first port?s write to the > second port is blocked while the second port is waiting for input. The first > port?s write proceeds only after the second port has timed out. > > ? > > I suppose I could have something twisted around in my code but I was > wondering if this is a know issue? > Hi Kirk, I've not seen a report like this. Perhaps some simple reproduction code will reveal a problem on your end or help us identify a problem in rxtx. I think there are several users doing multiport communication. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Wed Feb 3 07:03:58 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:03:58 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Message-ID: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> 2010/2/3 Ravishankar N > Hello Michael, > [..] > But on a side note, read(byte[]) in turn calls the read() in a loop.In the > native C function, the read is supposed to return a -1 upon timeout.But my > driver > does not support timeout.The default timeout value is zero and the linux > select call upon zero time out causes an infinite wait.What am i > missing...... > > When I have tested RXTX between platforms, I have observed "hangup" inside JNI driver when no data in Linux, is normal thing. Solution was setting the timeout for RXTX when no data from JNI driver. Something like that: commPort.enableReceiveTimeout(10); And it works perfect.... The only difference is that I am NOT using events - I am using continous read in separate thread and if data is available, is parsed and transferred to application using exception. Regards Mariusz > Thanks and regards, > Ravi > > Date: Wed, 3 Feb 2010 09:26:50 +0000 > From: Michael Erskine > To: "rxtx at qbang.org" > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > Message-ID: > > > Content-Type: text/plain; charset="us-ascii" > > > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of > > Ravishankar N > > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > > > My serial port driver(apparently) does not support receive timeout.I > > registered an event listener for DATA_AVAILABLE. However, the control > never > > seems to come out of the 'while' loop.Shouldn't the > > InputStream.read return a '-1' immediately if no data is available (this > seems > > to be the default operation)? > > Your event handler should handle the event and return immediately so that > its controlling thread can handle other events. I recommend a single read in > the following manner: rawbuf is a byte[] of "reasonable" size and the > read(byte[]) reads all available bytes up to the size of the buffer > returning the number of bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } > > This style of reading has worked for me with RXTX on Linux and Windows XP > for a good few years now in railway industry communications systems. Any > timeouts (largely unnecessary in my applications) can be handled elsewhere, > usually at a higher layer. > > Regards, > Michael Erskine. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Feb 3 07:22:55 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 3 Feb 2010 09:22:55 -0500 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: I'm guessing that this is driver specific. I recently had to support a select()/poll() infrastructure for a linux serial DD, its certainly non trivial to support async IO, so I suspect the problem in this case has to do with missing poll infrastructure in the device driver. This also has to coupled with special open flags for the device (which is within the rxtx code) The key routines within a 2.6 kernel linux device driver are shown below (if you have access to it for your particular device) are indicated below (here is a snippet from my device driver c code that supports polling/select). User space code to test this shown below also, note that the device needs to be opened with the O_NONBLOCK option to support the select/poll api // device driver code ..... /* * File operations supported by this driver. */ static struct file_operations iop_fops = { .owner = THIS_MODULE, .check_flags= iop_check_flags, .ioctl = iop_ioctl, .open = iop_open, .poll = iop_poll, // SUPPORT FOR SELECT/POLL infrastructure .read = iop_read, .release = iop_release, .write = iop_write, }; /** * Select/poll/epoll infrastructure. * * @param file * @param wait * * @return */ static unsigned int iop_poll(struct file *filp, poll_table *wait) { struct iop_device *devp = (struct iop_device *)filp->private_data; // the poll_table wait arg is an opaque pointer poll_wait(filp, &devp->readq, wait); // return from poll indicating whether we have read/write data unsigned int mask = 0; if (kfifo_len(devp->rx_fifo)) { mask |= (POLLIN | POLLRDNORM); } // @JC We don't do select on write yet // if (kfifo_len(devp->tx_fifo)) { // mask |= (POLLOUT | POLLWRNORM); // } // Only print out while debugging // if (mask != 0) { // printk (KERN_INFO "%s: [%04x]\n", __FUNCTION__, mask); // } return mask; } /** * device driver blocking and non blocking read function. This * function reads the requested number of bytes from the read * kfifo blocking as required. * * @param filp * @param buf * @param count * @param f_pos * * @return */ static ssize_t iop_read(struct file *filp, char __user *buf, size_t count, loff_t * ppos) { // access appropriate device struct struct iop_device *devp = (struct iop_device *) filp->private_data; ssize_t retval; // support non blocking mode (default) by checking if the kfifo is empty first if ((kfifo_len(devp->rx_fifo)==0) && (filp->f_flags & O_NONBLOCK)) { return -EAGAIN; } // wait for rx_fifo to receive data via receive interrupts retval = wait_event_interruptible(devp->readq, kfifo_len(devp->rx_fifo) != 0); // check for some error condition if (retval) { printk (KERN_ERR "%s: wait_event_interruptible returned[%d]\n", __FUNCTION__, retval); return retval; } // copy max requested bytes from rx_fifo to device buffer // this may still leave bytes in the kfifo for a subsequent read // if we are reading in a loop retval = kfifo_get(devp->rx_fifo, devp->rxbuf, count); // printk (KERN_INFO "%s: [%d] byte(s)\n", __FUNCTION__, retval); if (copy_to_user(buf, devp->rxbuf, retval)) { printk (KERN_ERR "%s: problem copying rx_fifo data to user buffer\n", __FUNCTION__); return -EFAULT; } return retval; } // a selection of my user space code reading via select()/poll()..... // user space open code iop_fd = ::open( deviceName.data(), O_RDWR | O_NONBLOCK); while ((bytes_to_expect - bytes_read) > 0) { // must reinitialize these between select calls fd_set readfds; FD_ZERO( &readfds ); FD_SET( iop_fd, &readfds ); // 1s sec read polling timeout struct timeval timeout; timeout.tv_sec = 1; timeout.tv_usec = 0; int rc = select( FD_SETSIZE, &readfds, NULL, NULL, &timeout ); // read from file when descriptor // indicates data available without blocking if ((rc > 0) && FD_ISSET(iop_fd, &readfds)) { // read into the appropriate offset within the rx_buf int temp = read(iop_fd, rx_buf + bytes_read, bytes_to_expect - bytes_read); if (!temp) { printf("EOF detected with %d bytes expected\n", bytes_to_expect - bytes_read); } else { bytes_read += temp; } } else if (rc < 0){ printf("%s: select on [%s], bytes_read[%d], errno=%d\n", __FUNCTION__, thread_args->device, bytes_read, errno); } else { printf("%s: select on [%s], bytes_read[%d], timeout\n", __FUNCTION__, thread_args->device, bytes_read); } } On Wed, Feb 3, 2010 at 9:03 AM, Mariusz Dec wrote: > > > 2010/2/3 Ravishankar N > >> Hello Michael, >> [..] >> >> But on a side note, read(byte[]) in turn calls the read() in a loop.In the >> native C function, the read is supposed to return a -1 upon timeout.But my >> driver >> does not support timeout.The default timeout value is zero and the linux >> select call upon zero time out causes an infinite wait.What am i >> missing...... >> >> > When I have tested RXTX between platforms, I have observed "hangup" inside > JNI driver when no data in Linux, is normal thing. > > Solution was setting the timeout for RXTX when no data from JNI driver. > > Something like that: > > commPort.enableReceiveTimeout(10); > > And it works perfect.... > > The only difference is that I am NOT using events - I am using continous > read in separate thread and if data is available, is parsed and transferred > to application using exception. > > Regards > Mariusz > > > >> Thanks and regards, >> Ravi >> >> Date: Wed, 3 Feb 2010 09:26:50 +0000 >> From: Michael Erskine >> To: "rxtx at qbang.org" >> Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? >> Message-ID: >> >> >> Content-Type: text/plain; charset="us-ascii" >> >> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >> Of >> > Ravishankar N >> > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? >> > >> > My serial port driver(apparently) does not support receive timeout.I >> > registered an event listener for DATA_AVAILABLE. However, the control >> never >> > seems to come out of the 'while' loop.Shouldn't the >> > InputStream.read return a '-1' immediately if no data is available (this >> seems >> > to be the default operation)? >> >> Your event handler should handle the event and return immediately so that >> its controlling thread can handle other events. I recommend a single read in >> the following manner: rawbuf is a byte[] of "reasonable" size and the >> read(byte[]) reads all available bytes up to the size of the buffer >> returning the number of bytes actually read... >> >> case SerialPortEvent.DATA_AVAILABLE: >> try { >> int i = is.read(rawbuf); >> if (i == -1) { >> << process EOF condition - should never happen >> >> return; >> } >> << process bytes (rawbuf, i); >> >> return; >> } catch (IOException e) { >> << promptly deal with exception >> >> return; >> } >> >> This style of reading has worked for me with RXTX on Linux and Windows XP >> for a good few years now in railway industry communications systems. Any >> timeouts (largely unnecessary in my applications) can be handled elsewhere, >> usually at a higher layer. >> >> Regards, >> Michael Erskine. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Feb 3 07:33:27 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:33:27 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: <73a89f361002030633j682610afia48dc7accd8e049b@mail.gmail.com> 2010/2/3 John Coffey > I'm guessing that this is driver specific. I recently had to support a > select()/poll() infrastructure for a linux serial DD, its certainly non > trivial to support async IO, so I suspect the problem in this case has to do > with missing poll infrastructure in the device driver. This also has to > coupled with special open flags for the device (which is within the rxtx > code) > > Yes, you are right, it may be driver specific, but in my case I haven't changed blocking JNI driver. I have added ONLY one call to RXTX method mentioned in my previous post and blocking (as seen as from Java app) gone out... Maybe this is not elegant, but works without problem in my app. I am using only FTDI chips and their drivers from couple of years and maybe this is the kind of the way to have no many problems with serial as well? Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From andyrxtx at g0poy.co.uk Wed Feb 3 11:09:04 2010 From: andyrxtx at g0poy.co.uk (andyrxtx at g0poy.co.uk) Date: Wed, 3 Feb 2010 18:09:04 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes Message-ID: <20100203180904.164f24dd@workstation.site> ?Hello RXTX group, I have just joined this group, and this is my first posting. I wanted to pass on some information regarding rxtx, so apologies if this has been brought up before. I have searched back through the archives but nothing specific came up. I am not a Java programmer, and I only came across rxtx a few days ago. I use a piece of test equipment called a miniVNA http://www.miniradiosolutions.com/ This is a serial USB controlled instrument, and it has control software available for MS windows, and a very old and now non-working Linux application. A few days ago Dietmar, DL2SBA released a Java application to control the miniVNA, obviously this application makes use of rxtx. The program worked fine on Windows, so I set about installing it onto Linux. I use SUSE11.1 After a few false starts, I got the system running fairly easily, sorting out the file locking by adding the uucp group to the users account as suggested (I used the 2.2pre binary files) I then passed the install instructions onto another miniVNA user, who also uses SUSE, but he ran into problems. To cut a long story short, he was also having file lock problems, but the uucp fix did not work. Digging into his system I found that there have been some changes in SUSE 11.2. tty ports are now assigned to the dialout group rather than uucp. A hint in the rxtx INSTALL file, suggested that var/lock needs to be checked, so: SUSE 11.1, var/lock is root:uucp SUSE 11.2 var/lock is root:root A search on Google brought up several comments regarding this, and also a bugzilla entry. https://bugzilla.novell.com/show_bug.cgi?id=552095 However from reading the various posts, some of which are in the bugzilla entry, it appears that many distros may be, or have changed to this configuration, and this will undoubtedly break several things, rxtx included. I solved my fellow SUSE users problem by compiling the rxtx libs with the no lock file option during configure, and that solved his problem. As this issue will probably take some time to get resolved across all the various Linux distros, it might be worth considering changing the default on the Linux build of rxtx not to use lockfiles, or provide the two versions of the lib in the binary archive. Thanks for your indulgence Andy From damorales at gmail.com Wed Feb 3 11:33:23 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 15:33:23 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203180904.164f24dd@workstation.site> References: <20100203180904.164f24dd@workstation.site> Message-ID: Hi I had the same problem in Mandriva 2010 and yes, adding the user to the uucp group did not work as it used to be in earlier versions of linux distros, causing RXTX to not work as non root user. The problem appears because the existense of UDEV, now you MUST add a RULE so the group (uucp or whatever) have access (Read, Write, Execute) to the Serial Port. To solve the problem, without needing to recompile RXTX, you must add a rule to grant permissions (0666) to the group for the device or port (tty*, ttyUSB*, etc). I do not remember now what is the line i added but when i come back home i will give it to you (i am at work now). Greetings ! 2010/2/3 > Hello RXTX group, > > I have just joined this group, and this is my first posting. > I wanted to pass on some information regarding rxtx, so apologies if > this has been brought up before. I have searched back through the > archives but nothing specific came up. > > I am not a Java programmer, and I only came across rxtx a few days ago. > > I use a piece of test equipment called a miniVNA > http://www.miniradiosolutions.com/ > > This is a serial USB controlled instrument, and it has control software > available for MS windows, and a very old and now non-working Linux > application. > > A few days ago Dietmar, DL2SBA released a Java application to control the > miniVNA, obviously this application makes use of rxtx. > > The program worked fine on Windows, so I set about installing it onto > Linux. I use SUSE11.1 After a few false starts, I got the system running > fairly easily, sorting out the file locking by adding the uucp group to > the users account as suggested (I used the 2.2pre binary files) I then > passed the install instructions onto another miniVNA user, who also uses > SUSE, but he ran into problems. To cut a long story short, he was > also having file lock problems, but the uucp fix did not work. Digging > into his system I found that there have been some changes in SUSE 11.2. > > tty ports are now assigned to the dialout group rather than uucp. > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > checked, so: > > SUSE 11.1, var/lock is root:uucp > SUSE 11.2 var/lock is root:root > > A search on Google brought up several comments regarding this, and also > a bugzilla entry. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > However from reading the various posts, some of which are in the bugzilla > entry, it appears that many distros may be, or have changed to this > configuration, and this will undoubtedly break several things, rxtx > included. > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > no lock file option during configure, and that solved his problem. > > As this issue will probably take some time to get resolved across all the > various Linux distros, it might be worth considering changing the default > on the Linux build of rxtx not to use lockfiles, or provide the two > versions of the lib in the binary archive. > > Thanks for your indulgence > > Andy > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Wed Feb 3 12:07:02 2010 From: andy at g0poy.com (Andy Eskelson) Date: Wed, 3 Feb 2010 19:07:02 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> Message-ID: <20100203190702.1b0e7015@workstation.site> Thanks Daniel, I am aware of the permissions problem, I have had a udev rules to solve this for other programs for some time. . I don't think that this is the same problem. as far as I can understand things, the lock files are written in var/lock. Previously var/lock and dev/tty-whatever were the same group. Now with var/lock owned by and with a group of root:root anything other than root cannot create a lock file. Even minicom is broken by this change. This change is going to have quite a few knock-on effects I think. Andy On Wed, 3 Feb 2010 15:33:23 -0300 Daniel Morales Salas wrote: > Hi > > I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > group did not work as it used to be in earlier versions of linux distros, > causing RXTX to not work as non root user. > > The problem appears because the existense of UDEV, now you MUST add a RULE > so the group (uucp or whatever) have access (Read, Write, Execute) to the > Serial Port. > > To solve the problem, without needing to recompile RXTX, you must add a rule > to grant permissions (0666) to the group for the device or port (tty*, > ttyUSB*, etc). I do not remember now what is the line i added but when i > come back home i will give it to you (i am at work now). > > Greetings ! > > 2010/2/3 > > > Hello RXTX group, > > > > I have just joined this group, and this is my first posting. > > I wanted to pass on some information regarding rxtx, so apologies if > > this has been brought up before. I have searched back through the > > archives but nothing specific came up. > > > > I am not a Java programmer, and I only came across rxtx a few days ago. > > > > I use a piece of test equipment called a miniVNA > > http://www.miniradiosolutions.com/ > > > > This is a serial USB controlled instrument, and it has control software > > available for MS windows, and a very old and now non-working Linux > > application. > > > > A few days ago Dietmar, DL2SBA released a Java application to control the > > miniVNA, obviously this application makes use of rxtx. > > > > The program worked fine on Windows, so I set about installing it onto > > Linux. I use SUSE11.1 After a few false starts, I got the system running > > fairly easily, sorting out the file locking by adding the uucp group to > > the users account as suggested (I used the 2.2pre binary files) I then > > passed the install instructions onto another miniVNA user, who also uses > > SUSE, but he ran into problems. To cut a long story short, he was > > also having file lock problems, but the uucp fix did not work. Digging > > into his system I found that there have been some changes in SUSE 11.2. > > > > tty ports are now assigned to the dialout group rather than uucp. > > > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > checked, so: > > > > SUSE 11.1, var/lock is root:uucp > > SUSE 11.2 var/lock is root:root > > > > A search on Google brought up several comments regarding this, and also > > a bugzilla entry. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > However from reading the various posts, some of which are in the bugzilla > > entry, it appears that many distros may be, or have changed to this > > configuration, and this will undoubtedly break several things, rxtx > > included. > > > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > > no lock file option during configure, and that solved his problem. > > > > As this issue will probably take some time to get resolved across all the > > various Linux distros, it might be worth considering changing the default > > on the Linux build of rxtx not to use lockfiles, or provide the two > > versions of the lib in the binary archive. > > > > Thanks for your indulgence > > > > Andy > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From thisdyingdream at gmail.com Wed Feb 3 12:32:35 2010 From: thisdyingdream at gmail.com (Steven Harms) Date: Wed, 3 Feb 2010 14:32:35 -0500 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203190702.1b0e7015@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: This is currently a bug in OpenSUSE that affects more than just rxtx, and is a result of unified udev rules. You can work around this by making udev change the group back to uucp until something more happens. https://bugzilla.novell.com/show_bug.cgi?id=552095 Thanks, Steve On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > Thanks Daniel, > > I am aware of the permissions problem, I have had a udev rules to solve > this for other programs for some time. > . > I don't think that this is the same problem. as far as I can understand > things, the lock files are written in var/lock. Previously var/lock and > dev/tty-whatever were the same group. Now with var/lock owned by and with > a group of root:root anything other than root cannot create a lock > file. Even minicom is broken by this change. > > This change is going to have quite a few knock-on effects I think. > > > Andy > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > Daniel Morales Salas wrote: > >> Hi >> >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp >> group did not work as it used to be in earlier versions of linux distros, >> causing RXTX to not work as non root user. >> >> The problem appears because the existense of UDEV, now you MUST add a RULE >> so the group (uucp or whatever) have access (Read, Write, Execute) to the >> Serial Port. >> >> To solve the problem, without needing to recompile RXTX, you must add a rule >> to grant permissions (0666) to the group for the device or port (tty*, >> ttyUSB*, etc). I do not remember now what is the line i added but when i >> come back home i will give it to you (i am at work now). >> >> Greetings ! >> >> 2010/2/3 >> >> > Hello RXTX group, >> > >> > I have just joined this group, and this is my first posting. >> > I wanted to pass on ?some information regarding rxtx, so apologies if >> > this has been brought up before. I have searched back through the >> > archives but nothing specific came up. >> > >> > I am not a Java programmer, and I only came across rxtx a few days ago. >> > >> > I use a piece of test equipment called a miniVNA >> > http://www.miniradiosolutions.com/ >> > >> > This is a serial USB controlled instrument, and it has control software >> > available for MS windows, and a very old and now non-working Linux >> > application. >> > >> > A few days ago Dietmar, DL2SBA released a Java application to control the >> > miniVNA, obviously this application makes use of rxtx. >> > >> > The program worked fine on Windows, so I set about installing it onto >> > Linux. I use SUSE11.1 After a few false starts, I got the system running >> > fairly easily, sorting out the file locking by adding the uucp group to >> > the users account as suggested (I used the 2.2pre binary files) I then >> > passed the install instructions onto another miniVNA user, who also uses >> > SUSE, but he ran into problems. To cut a long story short, he was >> > also having file lock problems, but the uucp fix did not work. Digging >> > into his system I found that there have been some changes in SUSE 11.2. >> > >> > tty ports are now assigned to the dialout group rather than uucp. >> > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be >> > checked, so: >> > >> > SUSE 11.1, var/lock is root:uucp >> > SUSE 11.2 var/lock is root:root >> > >> > A search on Google brought up several comments regarding this, and also >> > a ?bugzilla entry. >> > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 >> > >> > However from reading the various posts, some of which are in the bugzilla >> > entry, it appears that many distros may be, or have changed to this >> > configuration, and this will undoubtedly break several things, rxtx >> > included. >> > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the >> > no lock file option during configure, and that solved his problem. >> > >> > As this issue will probably take some time to get resolved across all the >> > various Linux distros, it might be worth considering changing the default >> > on the Linux build of rxtx not to use lockfiles, or provide the two >> > versions of the lib in the binary archive. >> > >> > Thanks for your indulgence >> > >> > Andy >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> >> >> >> -- >> Atte: >> Daniel Dario Morales Salas >> Ingeniero Civil en Computaci?n e Inform?tica >> Tel?fono: 02 684 3417 >> Celular: 09 643 1802 >> Santiago, Chile > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 WWW: http://www.sharms.org/blog From andy at g0poy.com Wed Feb 3 17:58:29 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 00:58:29 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: <20100204005829.7dc944e1@workstation.site> Thanks Steve, changing the serial ports back the uucp is not a big problem. I have a udev rule that can be easily modified already. However I cannot see any way of dealing with the var/lock problem apart from making it writable to all. Any thoughts? Andy On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms wrote: > This is currently a bug in OpenSUSE that affects more than just rxtx, > and is a result of unified udev rules. You can work around this by > making udev change the group back to uucp until something more > happens. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > Thanks, > > Steve > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > Thanks Daniel, > > > > I am aware of the permissions problem, I have had a udev rules to solve > > this for other programs for some time. > > . > > I don't think that this is the same problem. as far as I can understand > > things, the lock files are written in var/lock. Previously var/lock and > > dev/tty-whatever were the same group. Now with var/lock owned by and with > > a group of root:root anything other than root cannot create a lock > > file. Even minicom is broken by this change. > > > > This change is going to have quite a few knock-on effects I think. > > > > > > Andy > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > Daniel Morales Salas wrote: > > > >> Hi > >> > >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > >> group did not work as it used to be in earlier versions of linux distros, > >> causing RXTX to not work as non root user. > >> > >> The problem appears because the existense of UDEV, now you MUST add a RULE > >> so the group (uucp or whatever) have access (Read, Write, Execute) to the > >> Serial Port. > >> > >> To solve the problem, without needing to recompile RXTX, you must add a rule > >> to grant permissions (0666) to the group for the device or port (tty*, > >> ttyUSB*, etc). I do not remember now what is the line i added but when i > >> come back home i will give it to you (i am at work now). > >> > >> Greetings ! > >> > >> 2010/2/3 > >> > >> > Hello RXTX group, > >> > > >> > I have just joined this group, and this is my first posting. > >> > I wanted to pass on ?some information regarding rxtx, so apologies if > >> > this has been brought up before. I have searched back through the > >> > archives but nothing specific came up. > >> > > >> > I am not a Java programmer, and I only came across rxtx a few days ago. > >> > > >> > I use a piece of test equipment called a miniVNA > >> > http://www.miniradiosolutions.com/ > >> > > >> > This is a serial USB controlled instrument, and it has control software > >> > available for MS windows, and a very old and now non-working Linux > >> > application. > >> > > >> > A few days ago Dietmar, DL2SBA released a Java application to control the > >> > miniVNA, obviously this application makes use of rxtx. > >> > > >> > The program worked fine on Windows, so I set about installing it onto > >> > Linux. I use SUSE11.1 After a few false starts, I got the system running > >> > fairly easily, sorting out the file locking by adding the uucp group to > >> > the users account as suggested (I used the 2.2pre binary files) I then > >> > passed the install instructions onto another miniVNA user, who also uses > >> > SUSE, but he ran into problems. To cut a long story short, he was > >> > also having file lock problems, but the uucp fix did not work. Digging > >> > into his system I found that there have been some changes in SUSE 11.2. > >> > > >> > tty ports are now assigned to the dialout group rather than uucp. > >> > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > >> > checked, so: > >> > > >> > SUSE 11.1, var/lock is root:uucp > >> > SUSE 11.2 var/lock is root:root > >> > > >> > A search on Google brought up several comments regarding this, and also > >> > a ?bugzilla entry. > >> > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > >> > > >> > However from reading the various posts, some of which are in the bugzilla > >> > entry, it appears that many distros may be, or have changed to this > >> > configuration, and this will undoubtedly break several things, rxtx > >> > included. > >> > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the > >> > no lock file option during configure, and that solved his problem. > >> > > >> > As this issue will probably take some time to get resolved across all the > >> > various Linux distros, it might be worth considering changing the default > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > >> > versions of the lib in the binary archive. > >> > > >> > Thanks for your indulgence > >> > > >> > Andy > >> > > >> > _______________________________________________ > >> > Rxtx mailing list > >> > Rxtx at qbang.org > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > >> > >> > >> > >> -- > >> Atte: > >> Daniel Dario Morales Salas > >> Ingeniero Civil en Computaci?n e Inform?tica > >> Tel?fono: 02 684 3417 > >> Celular: 09 643 1802 > >> Santiago, Chile > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > WWW: http://www.sharms.org/blog From damorales at gmail.com Wed Feb 3 18:26:38 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 22:26:38 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100204005829.7dc944e1@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: Hello I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva 2010 this is what i get: drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ and i don't have ANY problem with lock files and RXTX in my java software. All i had to do was add this rule to udev: # serial KERNEL=="tty*", GROUP="uucp", MODE="0666" and that was all. Of course my user (metalklesk) is part of uucp group. I did not make /var/lock writable to all users. Greetings ! 2010/2/3 Andy Eskelson > Thanks Steve, > > changing the serial ports back the uucp is not a big problem. I have a > udev rule that can be easily modified already. However I cannot see any > way of dealing with the var/lock problem apart from making it writable to > all. Any thoughts? > > Andy > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > wrote: > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > and is a result of unified udev rules. You can work around this by > > making udev change the group back to uucp until something more > > happens. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > Thanks, > > > > Steve > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > Thanks Daniel, > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > this for other programs for some time. > > > . > > > I don't think that this is the same problem. as far as I can understand > > > things, the lock files are written in var/lock. Previously var/lock and > > > dev/tty-whatever were the same group. Now with var/lock owned by and > with > > > a group of root:root anything other than root cannot create a lock > > > file. Even minicom is broken by this change. > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > Daniel Morales Salas wrote: > > > > > >> Hi > > >> > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > the uucp > > >> group did not work as it used to be in earlier versions of linux > distros, > > >> causing RXTX to not work as non root user. > > >> > > >> The problem appears because the existense of UDEV, now you MUST add a > RULE > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > the > > >> Serial Port. > > >> > > >> To solve the problem, without needing to recompile RXTX, you must add > a rule > > >> to grant permissions (0666) to the group for the device or port (tty*, > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > i > > >> come back home i will give it to you (i am at work now). > > >> > > >> Greetings ! > > >> > > >> 2010/2/3 > > >> > > >> > Hello RXTX group, > > >> > > > >> > I have just joined this group, and this is my first posting. > > >> > I wanted to pass on some information regarding rxtx, so apologies > if > > >> > this has been brought up before. I have searched back through the > > >> > archives but nothing specific came up. > > >> > > > >> > I am not a Java programmer, and I only came across rxtx a few days > ago. > > >> > > > >> > I use a piece of test equipment called a miniVNA > > >> > http://www.miniradiosolutions.com/ > > >> > > > >> > This is a serial USB controlled instrument, and it has control > software > > >> > available for MS windows, and a very old and now non-working Linux > > >> > application. > > >> > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > control the > > >> > miniVNA, obviously this application makes use of rxtx. > > >> > > > >> > The program worked fine on Windows, so I set about installing it > onto > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > running > > >> > fairly easily, sorting out the file locking by adding the uucp group > to > > >> > the users account as suggested (I used the 2.2pre binary files) I > then > > >> > passed the install instructions onto another miniVNA user, who also > uses > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > >> > also having file lock problems, but the uucp fix did not work. > Digging > > >> > into his system I found that there have been some changes in SUSE > 11.2. > > >> > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > >> > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > >> > checked, so: > > >> > > > >> > SUSE 11.1, var/lock is root:uucp > > >> > SUSE 11.2 var/lock is root:root > > >> > > > >> > A search on Google brought up several comments regarding this, and > also > > >> > a bugzilla entry. > > >> > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > >> > > > >> > However from reading the various posts, some of which are in the > bugzilla > > >> > entry, it appears that many distros may be, or have changed to this > > >> > configuration, and this will undoubtedly break several things, rxtx > > >> > included. > > >> > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > with the > > >> > no lock file option during configure, and that solved his problem. > > >> > > > >> > As this issue will probably take some time to get resolved across > all the > > >> > various Linux distros, it might be worth considering changing the > default > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > >> > versions of the lib in the binary archive. > > >> > > > >> > Thanks for your indulgence > > >> > > > >> > Andy > > >> > > > >> > _______________________________________________ > > >> > Rxtx mailing list > > >> > Rxtx at qbang.org > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > >> > > > >> > > >> > > >> > > >> -- > > >> Atte: > > >> Daniel Dario Morales Salas > > >> Ingeniero Civil en Computaci?n e Inform?tica > > >> Tel?fono: 02 684 3417 > > >> Celular: 09 643 1802 > > >> Santiago, Chile > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at qbang.org > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > -- > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > WWW: http://www.sharms.org/blog > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Thu Feb 4 05:31:46 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 12:31:46 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: <20100204123146.6cffeb67@workstation.site> Thank's for the confirmation. Something odd is going on somewhere in SUSE 11.2. I'll have to build up a local SUSE11.2 system to see if I can nail down exactly what is going on. Something is blocking the lockfiles in var/lock. The net is nice, but it's a bit difficult trying to work out what is going on what the machine in question is in Germany and I'm in the UK :-) Andy On Wed, 3 Feb 2010 22:26:38 -0300 Daniel Morales Salas wrote: > Hello > > I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva > 2010 this is what i get: > > drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ > > and i don't have ANY problem with lock files and RXTX in my java software. > All i had to do was add this rule to udev: > > # serial > KERNEL=="tty*", GROUP="uucp", MODE="0666" > > and that was all. Of course my user (metalklesk) is part of uucp group. > I did not make /var/lock writable to all users. > > Greetings ! > > 2010/2/3 Andy Eskelson > > > Thanks Steve, > > > > changing the serial ports back the uucp is not a big problem. I have a > > udev rule that can be easily modified already. However I cannot see any > > way of dealing with the var/lock problem apart from making it writable to > > all. Any thoughts? > > > > Andy > > > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > > wrote: > > > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > > and is a result of unified udev rules. You can work around this by > > > making udev change the group back to uucp until something more > > > happens. > > > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > > > Thanks, > > > > > > Steve > > > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > > Thanks Daniel, > > > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > > this for other programs for some time. > > > > . > > > > I don't think that this is the same problem. as far as I can understand > > > > things, the lock files are written in var/lock. Previously var/lock and > > > > dev/tty-whatever were the same group. Now with var/lock owned by and > > with > > > > a group of root:root anything other than root cannot create a lock > > > > file. Even minicom is broken by this change. > > > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > > Daniel Morales Salas wrote: > > > > > > > >> Hi > > > >> > > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > > the uucp > > > >> group did not work as it used to be in earlier versions of linux > > distros, > > > >> causing RXTX to not work as non root user. > > > >> > > > >> The problem appears because the existense of UDEV, now you MUST add a > > RULE > > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > > the > > > >> Serial Port. > > > >> > > > >> To solve the problem, without needing to recompile RXTX, you must add > > a rule > > > >> to grant permissions (0666) to the group for the device or port (tty*, > > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > > i > > > >> come back home i will give it to you (i am at work now). > > > >> > > > >> Greetings ! > > > >> > > > >> 2010/2/3 > > > >> > > > >> > Hello RXTX group, > > > >> > > > > >> > I have just joined this group, and this is my first posting. > > > >> > I wanted to pass on some information regarding rxtx, so apologies > > if > > > >> > this has been brought up before. I have searched back through the > > > >> > archives but nothing specific came up. > > > >> > > > > >> > I am not a Java programmer, and I only came across rxtx a few days > > ago. > > > >> > > > > >> > I use a piece of test equipment called a miniVNA > > > >> > http://www.miniradiosolutions.com/ > > > >> > > > > >> > This is a serial USB controlled instrument, and it has control > > software > > > >> > available for MS windows, and a very old and now non-working Linux > > > >> > application. > > > >> > > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > > control the > > > >> > miniVNA, obviously this application makes use of rxtx. > > > >> > > > > >> > The program worked fine on Windows, so I set about installing it > > onto > > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > > running > > > >> > fairly easily, sorting out the file locking by adding the uucp group > > to > > > >> > the users account as suggested (I used the 2.2pre binary files) I > > then > > > >> > passed the install instructions onto another miniVNA user, who also > > uses > > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > > >> > also having file lock problems, but the uucp fix did not work. > > Digging > > > >> > into his system I found that there have been some changes in SUSE > > 11.2. > > > >> > > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > > >> > > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > > >> > checked, so: > > > >> > > > > >> > SUSE 11.1, var/lock is root:uucp > > > >> > SUSE 11.2 var/lock is root:root > > > >> > > > > >> > A search on Google brought up several comments regarding this, and > > also > > > >> > a bugzilla entry. > > > >> > > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > >> > > > > >> > However from reading the various posts, some of which are in the > > bugzilla > > > >> > entry, it appears that many distros may be, or have changed to this > > > >> > configuration, and this will undoubtedly break several things, rxtx > > > >> > included. > > > >> > > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > > with the > > > >> > no lock file option during configure, and that solved his problem. > > > >> > > > > >> > As this issue will probably take some time to get resolved across > > all the > > > >> > various Linux distros, it might be worth considering changing the > > default > > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > > >> > versions of the lib in the binary archive. > > > >> > > > > >> > Thanks for your indulgence > > > >> > > > > >> > Andy > > > >> > > > > >> > _______________________________________________ > > > >> > Rxtx mailing list > > > >> > Rxtx at qbang.org > > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > > >> > > > > >> > > > >> > > > >> > > > >> -- > > > >> Atte: > > > >> Daniel Dario Morales Salas > > > >> Ingeniero Civil en Computaci?n e Inform?tica > > > >> Tel?fono: 02 684 3417 > > > >> Celular: 09 643 1802 > > > >> Santiago, Chile > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at qbang.org > > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > > > -- > > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > > > WWW: http://www.sharms.org/blog > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From Bob_Jacobsen at lbl.gov Thu Feb 4 09:26:49 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Thu, 4 Feb 2010 08:26:49 -0800 Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 Message-ID: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're using RXTX-2.2pre2, although it emits the known message about "Version mismatch". WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 After the usual messing around, we've got it working on 11 Windows versions, multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ have things working rarely say so, so I don't know whether anybody has gotten it to work on 10.4 or not. The problem encountered is this: dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib dyld: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib followed by the JVM crashing hard. I've got those dump files if that would help. Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If so, is there a patch I can get and build? Thanks Bob -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From tjarvi at qbang.org Thu Feb 4 14:22:21 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 4 Feb 2010 14:22:21 -0700 (MST) Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 In-Reply-To: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> References: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> Message-ID: On Thu, 4 Feb 2010, Bob Jacobsen wrote: > We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're > using RXTX-2.2pre2, although it emits the known message about "Version > mismatch". > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > > After the usual messing around, we've got it working on 11 Windows versions, > multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with > a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ > have things working rarely say so, so I don't know whether anybody has gotten > it to work on 10.4 or not. > > The problem encountered is this: > > dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > dyld: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > followed by the JVM crashing hard. I've got those dump files if that would > help. > > Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If > so, is there a patch I can get and build? > Hi Bob, I talked to a coworker about the problem you ran into. It appears that it is possible to target 'older' Mac systems through makefile configuration changes. "Configuring a Makefile-Based Project If you have a makefile-based project, you can also take advantage of SDK-based development, by adding the appropriate options to your compile and link commands. Using SDKs in makefile-based projects requires GCC 4.0 or later. To choose an SDK, you use the -isysroot option with the compiler and the -syslibroot option with the linker. Both options require that you specify the full path to the desired SDK directory. To set the Deployment OS version in a makefile, use a makefile variable of the form: ENVP= MACOSX_DEPLOYMENT_TARGET=10.4. To use this variable in your makefile, include it in front of your compile and link commands." http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html Or build on the oldest system you want to support. -- Trent Jarvi tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Thu Feb 4 14:56:19 2010 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Thu, 4 Feb 2010 14:56:19 -0700 Subject: [Rxtx] RXTX on 64 Bit Redhat In-Reply-To: References: <4ec9eab61001281448g3dd84910r867619948a4e0d7a@mail.gmail.com> Message-ID: Trent -- Finally fixed all my build related issues. I ran into another issue. On one of my machines my JDK is returning multiple folders for the "java.ext.dirs" (java.ext.dirs -> /opt/jdk1.6.0_17/jre/lib/ext:/usr/java/packages/lib/ext) system property. As a result my JVM wasn't able to detect the gnu.io.rxtx.properties. I am attaching a patch for RXTXCommDriver.java file to check for multiple locations. Also i have to assign permission 660 to all my dev ports to be located by RXTX. Pawan ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 5:12 PM To: Trent Jarvi Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Here is the error i get when i build the src from release-2-1-7 -bash-3.2$ make ( \ \ cd i686-pc-linux-gnu; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/ jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I/opt/jav a1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec - c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialImp.lo;\ if [ "Serial" = "Serial" ]; then \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I /opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_tim espec -c /home/jb_stg/rxtx/rxtx-devel/./src/fuserImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ else \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo; \ fi; \ ) gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/inclu de -I/opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need _timespec -c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -fPIC -DPIC -o /hom e/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/.libs/SerialImp.o /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:25:29: error: gnu_io_RXTXPort.h: No such file or directory In file included from /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:113: /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:91: error: expected specifier-qua lifier-list before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'jobject' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:408: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:409: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:410: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:411: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:415: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:416: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:417: error: expected '=', ',', '; ', 'asm' or '__attribute__' before 'is_interrupted' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:418: error: expected declaration specifiers or '...' before 'jint' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:424: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:441: error: expected ')' before ' *' token ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 4:57 PM To: Santosh Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Santosh -- Thank you. That fixed the issue. All -- What CVS branch or release should i use to get the latest RXTX src code. Pawan ________________________________ From: Santosh [mailto:santosh.ry at gmail.com] Sent: Thursday, January 28, 2010 3:49 PM To: Kharbanda, Pawan Cc: Trent Jarvi; rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat error "./configure: /bin/sh^M: bad interpreter: No such file or directory". I think you need to run dos2unix on script files before compiling. Thanks, Santosh On Thu, Jan 28, 2010 at 5:33 PM, Kharbanda, Pawan > wrote: Trent -- We are upgrading our exisiting OS and JDK on a project that rely heavily on RXTX api's. We are now using JDK1.6 32 bit (build 1.6.0_17-b04) and RedHat 5 on a 64 bit machine. Linux tocrhstg02.dot.state.co.us 2.6.18-164.6.1.el5 #1 SMP Tue Oct 27 11:30:06 EDT 2009 i686 i686 i386 GNU/Linux Red Hat Enterprise Linux Server release 5.4 (Tikanga) I tried to run version 2.1.7 r2 on it but not able to see any of my Digi ports I was able to access only /dev/ttyS0 (physical ports). Not sure if the problem is with the Digi driver or RXTX. I tried to open a Digi port with minicom and it worked fine. I also tried to get latest from CVS (rxtx-devel) and when I do "configure" I see this error "./configure: /bin/sh^M: bad interpreter: No such file or directory". Can someone please help me with this? Thanks for the help. Pawan _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch.txt URL: From juan.vicente.l.g at gmail.com Sat Feb 13 04:44:17 2010 From: juan.vicente.l.g at gmail.com (Juan Vicente Lopez Gutierrez) Date: Sat, 13 Feb 2010 12:44:17 +0100 Subject: [Rxtx] RXTX in macmini OSX 10.5 Message-ID: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> Hello. My name is Juanvi and I'm from Spain. I tried to launch a software created by me in the library CXR java to send information through the serial port and I can not make it work. In windows if I've done but not mac. I have a mac mini with OSX 10.5 and have read in the list of web mail that you CXR if you have managed to make it work on that operating system. I need you help me please. Do I make the mistake that shows me java: run: Stable Library =============================== Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 gnu.io.PortInUseException: Unknow Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:26) at TwoWatSerialComm.main(TwoWaySerialComm.java:106) Experimental: JNI_OnLoad called. GENERACION CORRECTA (total time: 0 seconds) I do not have permission to access the serial port, do not know. Os agradeceria much to sit down. A greeting and thanks. Pardon my English. Juanvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From juan.vicente.l.g at gmail.com Sat Feb 13 14:39:41 2010 From: juan.vicente.l.g at gmail.com (Juan Vicente Lopez Gutierrez) Date: Sat, 13 Feb 2010 22:39:41 +0100 Subject: [Rxtx] Fwd: RXTX in macmini OSX 10.5 In-Reply-To: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> References: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> Message-ID: <29405e5c1002131339m2059d169sdc8549ed9706a1af@mail.gmail.com> ---------- Forwarded message ---------- From: Juan Vicente Lopez Gutierrez Date: 2010/2/13 Subject: RXTX in macmini OSX 10.5 To: rxtx at qbang.org Hello. My name is Juanvi and I'm from Spain. I tried to launch a software created by me in the library CXR java to send information through the serial port and I can not make it work. In windows if I've done but not mac. I have a mac mini with OSX 10.5 and have read in the list of web mail that you CXR if you have managed to make it work on that operating system. I need you help me please. Do I make the mistake that shows me java: run: Stable Library =============================== Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 gnu.io.PortInUseException: Unknow Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:26) at TwoWatSerialComm.main(TwoWaySerialComm.java:106) Experimental: JNI_OnLoad called. GENERACION CORRECTA (total time: 0 seconds) I do not have permission to access the serial port, do not know. Os agradeceria much to sit down. A greeting and thanks. Pardon my English. Juanvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Mon Feb 22 04:35:48 2010 From: george.dma at gmail.com (George H) Date: Mon, 22 Feb 2010 13:35:48 +0200 Subject: [Rxtx] Lingering rxtx process Message-ID: Hi, I am using RXTX v2.1-7. I use it to communicate with 2 serial receipt printers and 1 serial line display device. My program runs well using the RXTX library on Windows and Linux. But... when I installed Linux on another hardware the program does not exit properly. By this I mean that the java program seems to have exited (passed the System.exit(0)) code but the console still does not return to the bash shell. I have to CTRL+C each time to kill the program. And on each restart RXTX has to remove stale LCK files. Just note I am only getting this on one machine, if it makes any difference it is an i686 system with all VIA chipsets and VIA-C7M NannoBGA2 processor. Any ideas? Thanks -- George H george.dma at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Mon Feb 22 04:43:43 2010 From: george.dma at gmail.com (George H) Date: Mon, 22 Feb 2010 13:43:43 +0200 Subject: [Rxtx] Lingering rxtx process Message-ID: Hi, I am using RXTX v2.1-7. I use it to communicate with 2 serial receipt printers and 1 serial line display device. My program runs well using the RXTX library on Windows and Linux. But... when I installed Linux on another hardware the program does not exit properly. By this I mean that the java program seems to have exited (passed the System.exit(0)) code but the console still does not return to the bash shell. I have to CTRL+C each time to kill the program. And on each restart RXTX has to remove stale LCK files. Just note I am only getting this on one machine, if it makes any difference it is an i686 system with all VIA chipsets and VIA-C7M NannoBGA2 processor. Any ideas? Thanks -- George H george.dma at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Tue Feb 23 01:29:42 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Tue, 23 Feb 2010 09:29:42 +0100 Subject: [Rxtx] Lingering rxtx process In-Reply-To: References: Message-ID: <73a89f361002230029w4a9ec14bt56d654e43c1c9623@mail.gmail.com> 2010/2/22 George H > Hi, > > I am using RXTX v2.1-7. > I use it to communicate with 2 serial receipt printers and 1 serial line > display device. My program runs well using the RXTX library on Windows and > Linux. > But... when I installed Linux on another hardware the program does not exit > properly. By this I mean that the java program seems to have exited (passed > the System.exit(0)) code but the console still does not return to the bash > shell. > > Thread in Noember 2009' - http://mailman.qbang.org/pipermail/rxtx/2009-November/5778408.html I have disocvered one technique which solved this problem in Linux Ubuntu and Mac for RXTX pre2.2, but should helps in 2.1.7 as well. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 01:02:21 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 13:32:21 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> My serial port driver(apparently) does not support receive timeout.I registered an event listener for DATA_AVAILABLE. However, the control never seems to come out of the 'while' loop.Shouldn't the InputStream.read return a '-1' immediately if no data is available (this seems to be the default operation)? This was tried on a x86 Linux desktop using rxtx-2.1-7 I've added the snippet for clarity: /******************************************************************************************************************************************************************************/ mySerialPort.enableReceiveThreshold(2000);//Trying to set a time limit for read calls System.out.println(mySerialPort.isReceiveTimeoutEnabled()); // I get FALSE, so its not supported on hardware. mySerialPort.addEventListener(this); mySerialPort.notifyOnDataAvailable(true);//register a event with //my SerialEvent listener implementation: public void serialEvent(SerialPortEvent arg0) { int newData=0; switch(arg0.getEventType()){ case SerialPortEvent.DATA_AVAILABLE: while (newData != -1) { try { newData = is.read();//This should eventually return a -1 if no data is available within a timeout.PROBLEM!! System.out.println("Got a byte from port:"+newData); if (newData == -1) { break; } } catch (IOException ex) { System.err.println(ex); return; } } break; } return; } /******************************************************************************************************************************************************************************/ Thanks and regards, Ravi From michael.erskine at ketech.com Wed Feb 3 02:26:50 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 09:26:50 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From michael.erskine at ketech.com Wed Feb 3 05:03:30 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 12:03:30 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > Michael Erskine > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > > Your event handler should handle the event and return immediately so that its > controlling thread can handle other events. I recommend a single read in the > following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) > reads all available bytes up to the size of the buffer returning the number of > bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } After posting this I considered the glaring possibility of the rawbuf read buffer being too small to receive all the available bytes and perhaps skipping data: after all, I'm guessing that is why we see so many posts asking for help with blocking implementations of read event handlers looping on "while(bytes are available)". I've spent this morning writing an extensive multi-threaded unit test suite that includes tests with a tiny buffer compared to the amount of data available and found that no data was being skipped. I now want to know why! The SerialPortEvent.DATA_AVAILABLE event must be being fired again if there is more data available on the input stream. If that is the case then it should be heavily documented with good examples in the wiki to avoid the types of developer anguish we see so regularly. BTW: I'm not at liberty to post the JUnit tests as they use my company's unit test suite framework. Regards, Michael Erskine. From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 06:18:04 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 18:48:04 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Hello Michael, I tried out your suggestion but the problem is that the read(rawbuf) blocks until the entire length of the rawbuf array has been read (blocking). I cannot decide on a reasonable size of the array because it varies from 2 bytes to as much as 50 byes (i'm communicating with a modem,each response is of a different length), which is why i wanted to use non blocking calls. But on a side note, read(byte[]) in turn calls the read() in a loop.In the native C function, the read is supposed to return a -1 upon timeout.But my driver does not support timeout.The default timeout value is zero and the linux select call upon zero time out causes an infinite wait.What am i missing...... Thanks and regards, Ravi Date: Wed, 3 Feb 2010 09:26:50 +0000 From: Michael Erskine To: "rxtx at qbang.org" Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: Content-Type: text/plain; charset="us-ascii" > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From m.kirkland at comcast.net Wed Feb 3 06:46:03 2010 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 3 Feb 2010 05:46:03 -0800 Subject: [Rxtx] One port blocking another port In-Reply-To: References: Message-ID: <68768633814F4D7D86761D34F0764FE0@bengal.net> It turns out this is caused by having the RTS/CTS flow control turned on and me not providing a true on the RTS pin. Somehow it seems the port timing out on a read allows the write to proceed. This is not an issue for my application but I wonder if the write should not proceed until the RTS pin is true even if a read times out. mk -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Monday, January 25, 2010 7:48 PM To: Mike Kirkland Cc: rxtx at qbang.org Subject: Re: [Rxtx] One port blocking another port On Mon, 25 Jan 2010, Mike Kirkland wrote: > > Hi All, > > ? > > I have a program that reads from one com port and writes to another com > port. It also does the same thing in reverse (reads from the second com port > and writes to the first one. It basically ties two com ports together. > > ? > > One port is very chatty and has a consent stream of data. The other port has > very little data. > > ? > > Both ports use a 5000 ms (5 second) time out. > > ? > > The issue I am having is that is appears that the first port?s write to the > second port is blocked while the second port is waiting for input. The first > port?s write proceeds only after the second port has timed out. > > ? > > I suppose I could have something twisted around in my code but I was > wondering if this is a know issue? > Hi Kirk, I've not seen a report like this. Perhaps some simple reproduction code will reveal a problem on your end or help us identify a problem in rxtx. I think there are several users doing multiport communication. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Wed Feb 3 07:03:58 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:03:58 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Message-ID: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> 2010/2/3 Ravishankar N > Hello Michael, > [..] > But on a side note, read(byte[]) in turn calls the read() in a loop.In the > native C function, the read is supposed to return a -1 upon timeout.But my > driver > does not support timeout.The default timeout value is zero and the linux > select call upon zero time out causes an infinite wait.What am i > missing...... > > When I have tested RXTX between platforms, I have observed "hangup" inside JNI driver when no data in Linux, is normal thing. Solution was setting the timeout for RXTX when no data from JNI driver. Something like that: commPort.enableReceiveTimeout(10); And it works perfect.... The only difference is that I am NOT using events - I am using continous read in separate thread and if data is available, is parsed and transferred to application using exception. Regards Mariusz > Thanks and regards, > Ravi > > Date: Wed, 3 Feb 2010 09:26:50 +0000 > From: Michael Erskine > To: "rxtx at qbang.org" > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > Message-ID: > > > Content-Type: text/plain; charset="us-ascii" > > > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of > > Ravishankar N > > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > > > My serial port driver(apparently) does not support receive timeout.I > > registered an event listener for DATA_AVAILABLE. However, the control > never > > seems to come out of the 'while' loop.Shouldn't the > > InputStream.read return a '-1' immediately if no data is available (this > seems > > to be the default operation)? > > Your event handler should handle the event and return immediately so that > its controlling thread can handle other events. I recommend a single read in > the following manner: rawbuf is a byte[] of "reasonable" size and the > read(byte[]) reads all available bytes up to the size of the buffer > returning the number of bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } > > This style of reading has worked for me with RXTX on Linux and Windows XP > for a good few years now in railway industry communications systems. Any > timeouts (largely unnecessary in my applications) can be handled elsewhere, > usually at a higher layer. > > Regards, > Michael Erskine. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Feb 3 07:22:55 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 3 Feb 2010 09:22:55 -0500 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: I'm guessing that this is driver specific. I recently had to support a select()/poll() infrastructure for a linux serial DD, its certainly non trivial to support async IO, so I suspect the problem in this case has to do with missing poll infrastructure in the device driver. This also has to coupled with special open flags for the device (which is within the rxtx code) The key routines within a 2.6 kernel linux device driver are shown below (if you have access to it for your particular device) are indicated below (here is a snippet from my device driver c code that supports polling/select). User space code to test this shown below also, note that the device needs to be opened with the O_NONBLOCK option to support the select/poll api // device driver code ..... /* * File operations supported by this driver. */ static struct file_operations iop_fops = { .owner = THIS_MODULE, .check_flags= iop_check_flags, .ioctl = iop_ioctl, .open = iop_open, .poll = iop_poll, // SUPPORT FOR SELECT/POLL infrastructure .read = iop_read, .release = iop_release, .write = iop_write, }; /** * Select/poll/epoll infrastructure. * * @param file * @param wait * * @return */ static unsigned int iop_poll(struct file *filp, poll_table *wait) { struct iop_device *devp = (struct iop_device *)filp->private_data; // the poll_table wait arg is an opaque pointer poll_wait(filp, &devp->readq, wait); // return from poll indicating whether we have read/write data unsigned int mask = 0; if (kfifo_len(devp->rx_fifo)) { mask |= (POLLIN | POLLRDNORM); } // @JC We don't do select on write yet // if (kfifo_len(devp->tx_fifo)) { // mask |= (POLLOUT | POLLWRNORM); // } // Only print out while debugging // if (mask != 0) { // printk (KERN_INFO "%s: [%04x]\n", __FUNCTION__, mask); // } return mask; } /** * device driver blocking and non blocking read function. This * function reads the requested number of bytes from the read * kfifo blocking as required. * * @param filp * @param buf * @param count * @param f_pos * * @return */ static ssize_t iop_read(struct file *filp, char __user *buf, size_t count, loff_t * ppos) { // access appropriate device struct struct iop_device *devp = (struct iop_device *) filp->private_data; ssize_t retval; // support non blocking mode (default) by checking if the kfifo is empty first if ((kfifo_len(devp->rx_fifo)==0) && (filp->f_flags & O_NONBLOCK)) { return -EAGAIN; } // wait for rx_fifo to receive data via receive interrupts retval = wait_event_interruptible(devp->readq, kfifo_len(devp->rx_fifo) != 0); // check for some error condition if (retval) { printk (KERN_ERR "%s: wait_event_interruptible returned[%d]\n", __FUNCTION__, retval); return retval; } // copy max requested bytes from rx_fifo to device buffer // this may still leave bytes in the kfifo for a subsequent read // if we are reading in a loop retval = kfifo_get(devp->rx_fifo, devp->rxbuf, count); // printk (KERN_INFO "%s: [%d] byte(s)\n", __FUNCTION__, retval); if (copy_to_user(buf, devp->rxbuf, retval)) { printk (KERN_ERR "%s: problem copying rx_fifo data to user buffer\n", __FUNCTION__); return -EFAULT; } return retval; } // a selection of my user space code reading via select()/poll()..... // user space open code iop_fd = ::open( deviceName.data(), O_RDWR | O_NONBLOCK); while ((bytes_to_expect - bytes_read) > 0) { // must reinitialize these between select calls fd_set readfds; FD_ZERO( &readfds ); FD_SET( iop_fd, &readfds ); // 1s sec read polling timeout struct timeval timeout; timeout.tv_sec = 1; timeout.tv_usec = 0; int rc = select( FD_SETSIZE, &readfds, NULL, NULL, &timeout ); // read from file when descriptor // indicates data available without blocking if ((rc > 0) && FD_ISSET(iop_fd, &readfds)) { // read into the appropriate offset within the rx_buf int temp = read(iop_fd, rx_buf + bytes_read, bytes_to_expect - bytes_read); if (!temp) { printf("EOF detected with %d bytes expected\n", bytes_to_expect - bytes_read); } else { bytes_read += temp; } } else if (rc < 0){ printf("%s: select on [%s], bytes_read[%d], errno=%d\n", __FUNCTION__, thread_args->device, bytes_read, errno); } else { printf("%s: select on [%s], bytes_read[%d], timeout\n", __FUNCTION__, thread_args->device, bytes_read); } } On Wed, Feb 3, 2010 at 9:03 AM, Mariusz Dec wrote: > > > 2010/2/3 Ravishankar N > >> Hello Michael, >> [..] >> >> But on a side note, read(byte[]) in turn calls the read() in a loop.In the >> native C function, the read is supposed to return a -1 upon timeout.But my >> driver >> does not support timeout.The default timeout value is zero and the linux >> select call upon zero time out causes an infinite wait.What am i >> missing...... >> >> > When I have tested RXTX between platforms, I have observed "hangup" inside > JNI driver when no data in Linux, is normal thing. > > Solution was setting the timeout for RXTX when no data from JNI driver. > > Something like that: > > commPort.enableReceiveTimeout(10); > > And it works perfect.... > > The only difference is that I am NOT using events - I am using continous > read in separate thread and if data is available, is parsed and transferred > to application using exception. > > Regards > Mariusz > > > >> Thanks and regards, >> Ravi >> >> Date: Wed, 3 Feb 2010 09:26:50 +0000 >> From: Michael Erskine >> To: "rxtx at qbang.org" >> Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? >> Message-ID: >> >> >> Content-Type: text/plain; charset="us-ascii" >> >> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >> Of >> > Ravishankar N >> > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? >> > >> > My serial port driver(apparently) does not support receive timeout.I >> > registered an event listener for DATA_AVAILABLE. However, the control >> never >> > seems to come out of the 'while' loop.Shouldn't the >> > InputStream.read return a '-1' immediately if no data is available (this >> seems >> > to be the default operation)? >> >> Your event handler should handle the event and return immediately so that >> its controlling thread can handle other events. I recommend a single read in >> the following manner: rawbuf is a byte[] of "reasonable" size and the >> read(byte[]) reads all available bytes up to the size of the buffer >> returning the number of bytes actually read... >> >> case SerialPortEvent.DATA_AVAILABLE: >> try { >> int i = is.read(rawbuf); >> if (i == -1) { >> << process EOF condition - should never happen >> >> return; >> } >> << process bytes (rawbuf, i); >> >> return; >> } catch (IOException e) { >> << promptly deal with exception >> >> return; >> } >> >> This style of reading has worked for me with RXTX on Linux and Windows XP >> for a good few years now in railway industry communications systems. Any >> timeouts (largely unnecessary in my applications) can be handled elsewhere, >> usually at a higher layer. >> >> Regards, >> Michael Erskine. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Feb 3 07:33:27 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:33:27 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: <73a89f361002030633j682610afia48dc7accd8e049b@mail.gmail.com> 2010/2/3 John Coffey > I'm guessing that this is driver specific. I recently had to support a > select()/poll() infrastructure for a linux serial DD, its certainly non > trivial to support async IO, so I suspect the problem in this case has to do > with missing poll infrastructure in the device driver. This also has to > coupled with special open flags for the device (which is within the rxtx > code) > > Yes, you are right, it may be driver specific, but in my case I haven't changed blocking JNI driver. I have added ONLY one call to RXTX method mentioned in my previous post and blocking (as seen as from Java app) gone out... Maybe this is not elegant, but works without problem in my app. I am using only FTDI chips and their drivers from couple of years and maybe this is the kind of the way to have no many problems with serial as well? Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From andyrxtx at g0poy.co.uk Wed Feb 3 11:09:04 2010 From: andyrxtx at g0poy.co.uk (andyrxtx at g0poy.co.uk) Date: Wed, 3 Feb 2010 18:09:04 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes Message-ID: <20100203180904.164f24dd@workstation.site> ?Hello RXTX group, I have just joined this group, and this is my first posting. I wanted to pass on some information regarding rxtx, so apologies if this has been brought up before. I have searched back through the archives but nothing specific came up. I am not a Java programmer, and I only came across rxtx a few days ago. I use a piece of test equipment called a miniVNA http://www.miniradiosolutions.com/ This is a serial USB controlled instrument, and it has control software available for MS windows, and a very old and now non-working Linux application. A few days ago Dietmar, DL2SBA released a Java application to control the miniVNA, obviously this application makes use of rxtx. The program worked fine on Windows, so I set about installing it onto Linux. I use SUSE11.1 After a few false starts, I got the system running fairly easily, sorting out the file locking by adding the uucp group to the users account as suggested (I used the 2.2pre binary files) I then passed the install instructions onto another miniVNA user, who also uses SUSE, but he ran into problems. To cut a long story short, he was also having file lock problems, but the uucp fix did not work. Digging into his system I found that there have been some changes in SUSE 11.2. tty ports are now assigned to the dialout group rather than uucp. A hint in the rxtx INSTALL file, suggested that var/lock needs to be checked, so: SUSE 11.1, var/lock is root:uucp SUSE 11.2 var/lock is root:root A search on Google brought up several comments regarding this, and also a bugzilla entry. https://bugzilla.novell.com/show_bug.cgi?id=552095 However from reading the various posts, some of which are in the bugzilla entry, it appears that many distros may be, or have changed to this configuration, and this will undoubtedly break several things, rxtx included. I solved my fellow SUSE users problem by compiling the rxtx libs with the no lock file option during configure, and that solved his problem. As this issue will probably take some time to get resolved across all the various Linux distros, it might be worth considering changing the default on the Linux build of rxtx not to use lockfiles, or provide the two versions of the lib in the binary archive. Thanks for your indulgence Andy From damorales at gmail.com Wed Feb 3 11:33:23 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 15:33:23 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203180904.164f24dd@workstation.site> References: <20100203180904.164f24dd@workstation.site> Message-ID: Hi I had the same problem in Mandriva 2010 and yes, adding the user to the uucp group did not work as it used to be in earlier versions of linux distros, causing RXTX to not work as non root user. The problem appears because the existense of UDEV, now you MUST add a RULE so the group (uucp or whatever) have access (Read, Write, Execute) to the Serial Port. To solve the problem, without needing to recompile RXTX, you must add a rule to grant permissions (0666) to the group for the device or port (tty*, ttyUSB*, etc). I do not remember now what is the line i added but when i come back home i will give it to you (i am at work now). Greetings ! 2010/2/3 > Hello RXTX group, > > I have just joined this group, and this is my first posting. > I wanted to pass on some information regarding rxtx, so apologies if > this has been brought up before. I have searched back through the > archives but nothing specific came up. > > I am not a Java programmer, and I only came across rxtx a few days ago. > > I use a piece of test equipment called a miniVNA > http://www.miniradiosolutions.com/ > > This is a serial USB controlled instrument, and it has control software > available for MS windows, and a very old and now non-working Linux > application. > > A few days ago Dietmar, DL2SBA released a Java application to control the > miniVNA, obviously this application makes use of rxtx. > > The program worked fine on Windows, so I set about installing it onto > Linux. I use SUSE11.1 After a few false starts, I got the system running > fairly easily, sorting out the file locking by adding the uucp group to > the users account as suggested (I used the 2.2pre binary files) I then > passed the install instructions onto another miniVNA user, who also uses > SUSE, but he ran into problems. To cut a long story short, he was > also having file lock problems, but the uucp fix did not work. Digging > into his system I found that there have been some changes in SUSE 11.2. > > tty ports are now assigned to the dialout group rather than uucp. > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > checked, so: > > SUSE 11.1, var/lock is root:uucp > SUSE 11.2 var/lock is root:root > > A search on Google brought up several comments regarding this, and also > a bugzilla entry. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > However from reading the various posts, some of which are in the bugzilla > entry, it appears that many distros may be, or have changed to this > configuration, and this will undoubtedly break several things, rxtx > included. > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > no lock file option during configure, and that solved his problem. > > As this issue will probably take some time to get resolved across all the > various Linux distros, it might be worth considering changing the default > on the Linux build of rxtx not to use lockfiles, or provide the two > versions of the lib in the binary archive. > > Thanks for your indulgence > > Andy > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Wed Feb 3 12:07:02 2010 From: andy at g0poy.com (Andy Eskelson) Date: Wed, 3 Feb 2010 19:07:02 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> Message-ID: <20100203190702.1b0e7015@workstation.site> Thanks Daniel, I am aware of the permissions problem, I have had a udev rules to solve this for other programs for some time. . I don't think that this is the same problem. as far as I can understand things, the lock files are written in var/lock. Previously var/lock and dev/tty-whatever were the same group. Now with var/lock owned by and with a group of root:root anything other than root cannot create a lock file. Even minicom is broken by this change. This change is going to have quite a few knock-on effects I think. Andy On Wed, 3 Feb 2010 15:33:23 -0300 Daniel Morales Salas wrote: > Hi > > I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > group did not work as it used to be in earlier versions of linux distros, > causing RXTX to not work as non root user. > > The problem appears because the existense of UDEV, now you MUST add a RULE > so the group (uucp or whatever) have access (Read, Write, Execute) to the > Serial Port. > > To solve the problem, without needing to recompile RXTX, you must add a rule > to grant permissions (0666) to the group for the device or port (tty*, > ttyUSB*, etc). I do not remember now what is the line i added but when i > come back home i will give it to you (i am at work now). > > Greetings ! > > 2010/2/3 > > > Hello RXTX group, > > > > I have just joined this group, and this is my first posting. > > I wanted to pass on some information regarding rxtx, so apologies if > > this has been brought up before. I have searched back through the > > archives but nothing specific came up. > > > > I am not a Java programmer, and I only came across rxtx a few days ago. > > > > I use a piece of test equipment called a miniVNA > > http://www.miniradiosolutions.com/ > > > > This is a serial USB controlled instrument, and it has control software > > available for MS windows, and a very old and now non-working Linux > > application. > > > > A few days ago Dietmar, DL2SBA released a Java application to control the > > miniVNA, obviously this application makes use of rxtx. > > > > The program worked fine on Windows, so I set about installing it onto > > Linux. I use SUSE11.1 After a few false starts, I got the system running > > fairly easily, sorting out the file locking by adding the uucp group to > > the users account as suggested (I used the 2.2pre binary files) I then > > passed the install instructions onto another miniVNA user, who also uses > > SUSE, but he ran into problems. To cut a long story short, he was > > also having file lock problems, but the uucp fix did not work. Digging > > into his system I found that there have been some changes in SUSE 11.2. > > > > tty ports are now assigned to the dialout group rather than uucp. > > > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > checked, so: > > > > SUSE 11.1, var/lock is root:uucp > > SUSE 11.2 var/lock is root:root > > > > A search on Google brought up several comments regarding this, and also > > a bugzilla entry. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > However from reading the various posts, some of which are in the bugzilla > > entry, it appears that many distros may be, or have changed to this > > configuration, and this will undoubtedly break several things, rxtx > > included. > > > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > > no lock file option during configure, and that solved his problem. > > > > As this issue will probably take some time to get resolved across all the > > various Linux distros, it might be worth considering changing the default > > on the Linux build of rxtx not to use lockfiles, or provide the two > > versions of the lib in the binary archive. > > > > Thanks for your indulgence > > > > Andy > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From thisdyingdream at gmail.com Wed Feb 3 12:32:35 2010 From: thisdyingdream at gmail.com (Steven Harms) Date: Wed, 3 Feb 2010 14:32:35 -0500 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203190702.1b0e7015@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: This is currently a bug in OpenSUSE that affects more than just rxtx, and is a result of unified udev rules. You can work around this by making udev change the group back to uucp until something more happens. https://bugzilla.novell.com/show_bug.cgi?id=552095 Thanks, Steve On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > Thanks Daniel, > > I am aware of the permissions problem, I have had a udev rules to solve > this for other programs for some time. > . > I don't think that this is the same problem. as far as I can understand > things, the lock files are written in var/lock. Previously var/lock and > dev/tty-whatever were the same group. Now with var/lock owned by and with > a group of root:root anything other than root cannot create a lock > file. Even minicom is broken by this change. > > This change is going to have quite a few knock-on effects I think. > > > Andy > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > Daniel Morales Salas wrote: > >> Hi >> >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp >> group did not work as it used to be in earlier versions of linux distros, >> causing RXTX to not work as non root user. >> >> The problem appears because the existense of UDEV, now you MUST add a RULE >> so the group (uucp or whatever) have access (Read, Write, Execute) to the >> Serial Port. >> >> To solve the problem, without needing to recompile RXTX, you must add a rule >> to grant permissions (0666) to the group for the device or port (tty*, >> ttyUSB*, etc). I do not remember now what is the line i added but when i >> come back home i will give it to you (i am at work now). >> >> Greetings ! >> >> 2010/2/3 >> >> > Hello RXTX group, >> > >> > I have just joined this group, and this is my first posting. >> > I wanted to pass on ?some information regarding rxtx, so apologies if >> > this has been brought up before. I have searched back through the >> > archives but nothing specific came up. >> > >> > I am not a Java programmer, and I only came across rxtx a few days ago. >> > >> > I use a piece of test equipment called a miniVNA >> > http://www.miniradiosolutions.com/ >> > >> > This is a serial USB controlled instrument, and it has control software >> > available for MS windows, and a very old and now non-working Linux >> > application. >> > >> > A few days ago Dietmar, DL2SBA released a Java application to control the >> > miniVNA, obviously this application makes use of rxtx. >> > >> > The program worked fine on Windows, so I set about installing it onto >> > Linux. I use SUSE11.1 After a few false starts, I got the system running >> > fairly easily, sorting out the file locking by adding the uucp group to >> > the users account as suggested (I used the 2.2pre binary files) I then >> > passed the install instructions onto another miniVNA user, who also uses >> > SUSE, but he ran into problems. To cut a long story short, he was >> > also having file lock problems, but the uucp fix did not work. Digging >> > into his system I found that there have been some changes in SUSE 11.2. >> > >> > tty ports are now assigned to the dialout group rather than uucp. >> > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be >> > checked, so: >> > >> > SUSE 11.1, var/lock is root:uucp >> > SUSE 11.2 var/lock is root:root >> > >> > A search on Google brought up several comments regarding this, and also >> > a ?bugzilla entry. >> > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 >> > >> > However from reading the various posts, some of which are in the bugzilla >> > entry, it appears that many distros may be, or have changed to this >> > configuration, and this will undoubtedly break several things, rxtx >> > included. >> > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the >> > no lock file option during configure, and that solved his problem. >> > >> > As this issue will probably take some time to get resolved across all the >> > various Linux distros, it might be worth considering changing the default >> > on the Linux build of rxtx not to use lockfiles, or provide the two >> > versions of the lib in the binary archive. >> > >> > Thanks for your indulgence >> > >> > Andy >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> >> >> >> -- >> Atte: >> Daniel Dario Morales Salas >> Ingeniero Civil en Computaci?n e Inform?tica >> Tel?fono: 02 684 3417 >> Celular: 09 643 1802 >> Santiago, Chile > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 WWW: http://www.sharms.org/blog From andy at g0poy.com Wed Feb 3 17:58:29 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 00:58:29 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: <20100204005829.7dc944e1@workstation.site> Thanks Steve, changing the serial ports back the uucp is not a big problem. I have a udev rule that can be easily modified already. However I cannot see any way of dealing with the var/lock problem apart from making it writable to all. Any thoughts? Andy On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms wrote: > This is currently a bug in OpenSUSE that affects more than just rxtx, > and is a result of unified udev rules. You can work around this by > making udev change the group back to uucp until something more > happens. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > Thanks, > > Steve > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > Thanks Daniel, > > > > I am aware of the permissions problem, I have had a udev rules to solve > > this for other programs for some time. > > . > > I don't think that this is the same problem. as far as I can understand > > things, the lock files are written in var/lock. Previously var/lock and > > dev/tty-whatever were the same group. Now with var/lock owned by and with > > a group of root:root anything other than root cannot create a lock > > file. Even minicom is broken by this change. > > > > This change is going to have quite a few knock-on effects I think. > > > > > > Andy > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > Daniel Morales Salas wrote: > > > >> Hi > >> > >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > >> group did not work as it used to be in earlier versions of linux distros, > >> causing RXTX to not work as non root user. > >> > >> The problem appears because the existense of UDEV, now you MUST add a RULE > >> so the group (uucp or whatever) have access (Read, Write, Execute) to the > >> Serial Port. > >> > >> To solve the problem, without needing to recompile RXTX, you must add a rule > >> to grant permissions (0666) to the group for the device or port (tty*, > >> ttyUSB*, etc). I do not remember now what is the line i added but when i > >> come back home i will give it to you (i am at work now). > >> > >> Greetings ! > >> > >> 2010/2/3 > >> > >> > Hello RXTX group, > >> > > >> > I have just joined this group, and this is my first posting. > >> > I wanted to pass on ?some information regarding rxtx, so apologies if > >> > this has been brought up before. I have searched back through the > >> > archives but nothing specific came up. > >> > > >> > I am not a Java programmer, and I only came across rxtx a few days ago. > >> > > >> > I use a piece of test equipment called a miniVNA > >> > http://www.miniradiosolutions.com/ > >> > > >> > This is a serial USB controlled instrument, and it has control software > >> > available for MS windows, and a very old and now non-working Linux > >> > application. > >> > > >> > A few days ago Dietmar, DL2SBA released a Java application to control the > >> > miniVNA, obviously this application makes use of rxtx. > >> > > >> > The program worked fine on Windows, so I set about installing it onto > >> > Linux. I use SUSE11.1 After a few false starts, I got the system running > >> > fairly easily, sorting out the file locking by adding the uucp group to > >> > the users account as suggested (I used the 2.2pre binary files) I then > >> > passed the install instructions onto another miniVNA user, who also uses > >> > SUSE, but he ran into problems. To cut a long story short, he was > >> > also having file lock problems, but the uucp fix did not work. Digging > >> > into his system I found that there have been some changes in SUSE 11.2. > >> > > >> > tty ports are now assigned to the dialout group rather than uucp. > >> > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > >> > checked, so: > >> > > >> > SUSE 11.1, var/lock is root:uucp > >> > SUSE 11.2 var/lock is root:root > >> > > >> > A search on Google brought up several comments regarding this, and also > >> > a ?bugzilla entry. > >> > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > >> > > >> > However from reading the various posts, some of which are in the bugzilla > >> > entry, it appears that many distros may be, or have changed to this > >> > configuration, and this will undoubtedly break several things, rxtx > >> > included. > >> > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the > >> > no lock file option during configure, and that solved his problem. > >> > > >> > As this issue will probably take some time to get resolved across all the > >> > various Linux distros, it might be worth considering changing the default > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > >> > versions of the lib in the binary archive. > >> > > >> > Thanks for your indulgence > >> > > >> > Andy > >> > > >> > _______________________________________________ > >> > Rxtx mailing list > >> > Rxtx at qbang.org > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > >> > >> > >> > >> -- > >> Atte: > >> Daniel Dario Morales Salas > >> Ingeniero Civil en Computaci?n e Inform?tica > >> Tel?fono: 02 684 3417 > >> Celular: 09 643 1802 > >> Santiago, Chile > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > WWW: http://www.sharms.org/blog From damorales at gmail.com Wed Feb 3 18:26:38 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 22:26:38 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100204005829.7dc944e1@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: Hello I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva 2010 this is what i get: drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ and i don't have ANY problem with lock files and RXTX in my java software. All i had to do was add this rule to udev: # serial KERNEL=="tty*", GROUP="uucp", MODE="0666" and that was all. Of course my user (metalklesk) is part of uucp group. I did not make /var/lock writable to all users. Greetings ! 2010/2/3 Andy Eskelson > Thanks Steve, > > changing the serial ports back the uucp is not a big problem. I have a > udev rule that can be easily modified already. However I cannot see any > way of dealing with the var/lock problem apart from making it writable to > all. Any thoughts? > > Andy > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > wrote: > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > and is a result of unified udev rules. You can work around this by > > making udev change the group back to uucp until something more > > happens. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > Thanks, > > > > Steve > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > Thanks Daniel, > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > this for other programs for some time. > > > . > > > I don't think that this is the same problem. as far as I can understand > > > things, the lock files are written in var/lock. Previously var/lock and > > > dev/tty-whatever were the same group. Now with var/lock owned by and > with > > > a group of root:root anything other than root cannot create a lock > > > file. Even minicom is broken by this change. > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > Daniel Morales Salas wrote: > > > > > >> Hi > > >> > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > the uucp > > >> group did not work as it used to be in earlier versions of linux > distros, > > >> causing RXTX to not work as non root user. > > >> > > >> The problem appears because the existense of UDEV, now you MUST add a > RULE > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > the > > >> Serial Port. > > >> > > >> To solve the problem, without needing to recompile RXTX, you must add > a rule > > >> to grant permissions (0666) to the group for the device or port (tty*, > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > i > > >> come back home i will give it to you (i am at work now). > > >> > > >> Greetings ! > > >> > > >> 2010/2/3 > > >> > > >> > Hello RXTX group, > > >> > > > >> > I have just joined this group, and this is my first posting. > > >> > I wanted to pass on some information regarding rxtx, so apologies > if > > >> > this has been brought up before. I have searched back through the > > >> > archives but nothing specific came up. > > >> > > > >> > I am not a Java programmer, and I only came across rxtx a few days > ago. > > >> > > > >> > I use a piece of test equipment called a miniVNA > > >> > http://www.miniradiosolutions.com/ > > >> > > > >> > This is a serial USB controlled instrument, and it has control > software > > >> > available for MS windows, and a very old and now non-working Linux > > >> > application. > > >> > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > control the > > >> > miniVNA, obviously this application makes use of rxtx. > > >> > > > >> > The program worked fine on Windows, so I set about installing it > onto > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > running > > >> > fairly easily, sorting out the file locking by adding the uucp group > to > > >> > the users account as suggested (I used the 2.2pre binary files) I > then > > >> > passed the install instructions onto another miniVNA user, who also > uses > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > >> > also having file lock problems, but the uucp fix did not work. > Digging > > >> > into his system I found that there have been some changes in SUSE > 11.2. > > >> > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > >> > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > >> > checked, so: > > >> > > > >> > SUSE 11.1, var/lock is root:uucp > > >> > SUSE 11.2 var/lock is root:root > > >> > > > >> > A search on Google brought up several comments regarding this, and > also > > >> > a bugzilla entry. > > >> > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > >> > > > >> > However from reading the various posts, some of which are in the > bugzilla > > >> > entry, it appears that many distros may be, or have changed to this > > >> > configuration, and this will undoubtedly break several things, rxtx > > >> > included. > > >> > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > with the > > >> > no lock file option during configure, and that solved his problem. > > >> > > > >> > As this issue will probably take some time to get resolved across > all the > > >> > various Linux distros, it might be worth considering changing the > default > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > >> > versions of the lib in the binary archive. > > >> > > > >> > Thanks for your indulgence > > >> > > > >> > Andy > > >> > > > >> > _______________________________________________ > > >> > Rxtx mailing list > > >> > Rxtx at qbang.org > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > >> > > > >> > > >> > > >> > > >> -- > > >> Atte: > > >> Daniel Dario Morales Salas > > >> Ingeniero Civil en Computaci?n e Inform?tica > > >> Tel?fono: 02 684 3417 > > >> Celular: 09 643 1802 > > >> Santiago, Chile > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at qbang.org > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > -- > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > WWW: http://www.sharms.org/blog > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Thu Feb 4 05:31:46 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 12:31:46 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: <20100204123146.6cffeb67@workstation.site> Thank's for the confirmation. Something odd is going on somewhere in SUSE 11.2. I'll have to build up a local SUSE11.2 system to see if I can nail down exactly what is going on. Something is blocking the lockfiles in var/lock. The net is nice, but it's a bit difficult trying to work out what is going on what the machine in question is in Germany and I'm in the UK :-) Andy On Wed, 3 Feb 2010 22:26:38 -0300 Daniel Morales Salas wrote: > Hello > > I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva > 2010 this is what i get: > > drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ > > and i don't have ANY problem with lock files and RXTX in my java software. > All i had to do was add this rule to udev: > > # serial > KERNEL=="tty*", GROUP="uucp", MODE="0666" > > and that was all. Of course my user (metalklesk) is part of uucp group. > I did not make /var/lock writable to all users. > > Greetings ! > > 2010/2/3 Andy Eskelson > > > Thanks Steve, > > > > changing the serial ports back the uucp is not a big problem. I have a > > udev rule that can be easily modified already. However I cannot see any > > way of dealing with the var/lock problem apart from making it writable to > > all. Any thoughts? > > > > Andy > > > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > > wrote: > > > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > > and is a result of unified udev rules. You can work around this by > > > making udev change the group back to uucp until something more > > > happens. > > > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > > > Thanks, > > > > > > Steve > > > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > > Thanks Daniel, > > > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > > this for other programs for some time. > > > > . > > > > I don't think that this is the same problem. as far as I can understand > > > > things, the lock files are written in var/lock. Previously var/lock and > > > > dev/tty-whatever were the same group. Now with var/lock owned by and > > with > > > > a group of root:root anything other than root cannot create a lock > > > > file. Even minicom is broken by this change. > > > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > > Daniel Morales Salas wrote: > > > > > > > >> Hi > > > >> > > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > > the uucp > > > >> group did not work as it used to be in earlier versions of linux > > distros, > > > >> causing RXTX to not work as non root user. > > > >> > > > >> The problem appears because the existense of UDEV, now you MUST add a > > RULE > > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > > the > > > >> Serial Port. > > > >> > > > >> To solve the problem, without needing to recompile RXTX, you must add > > a rule > > > >> to grant permissions (0666) to the group for the device or port (tty*, > > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > > i > > > >> come back home i will give it to you (i am at work now). > > > >> > > > >> Greetings ! > > > >> > > > >> 2010/2/3 > > > >> > > > >> > Hello RXTX group, > > > >> > > > > >> > I have just joined this group, and this is my first posting. > > > >> > I wanted to pass on some information regarding rxtx, so apologies > > if > > > >> > this has been brought up before. I have searched back through the > > > >> > archives but nothing specific came up. > > > >> > > > > >> > I am not a Java programmer, and I only came across rxtx a few days > > ago. > > > >> > > > > >> > I use a piece of test equipment called a miniVNA > > > >> > http://www.miniradiosolutions.com/ > > > >> > > > > >> > This is a serial USB controlled instrument, and it has control > > software > > > >> > available for MS windows, and a very old and now non-working Linux > > > >> > application. > > > >> > > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > > control the > > > >> > miniVNA, obviously this application makes use of rxtx. > > > >> > > > > >> > The program worked fine on Windows, so I set about installing it > > onto > > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > > running > > > >> > fairly easily, sorting out the file locking by adding the uucp group > > to > > > >> > the users account as suggested (I used the 2.2pre binary files) I > > then > > > >> > passed the install instructions onto another miniVNA user, who also > > uses > > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > > >> > also having file lock problems, but the uucp fix did not work. > > Digging > > > >> > into his system I found that there have been some changes in SUSE > > 11.2. > > > >> > > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > > >> > > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > > >> > checked, so: > > > >> > > > > >> > SUSE 11.1, var/lock is root:uucp > > > >> > SUSE 11.2 var/lock is root:root > > > >> > > > > >> > A search on Google brought up several comments regarding this, and > > also > > > >> > a bugzilla entry. > > > >> > > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > >> > > > > >> > However from reading the various posts, some of which are in the > > bugzilla > > > >> > entry, it appears that many distros may be, or have changed to this > > > >> > configuration, and this will undoubtedly break several things, rxtx > > > >> > included. > > > >> > > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > > with the > > > >> > no lock file option during configure, and that solved his problem. > > > >> > > > > >> > As this issue will probably take some time to get resolved across > > all the > > > >> > various Linux distros, it might be worth considering changing the > > default > > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > > >> > versions of the lib in the binary archive. > > > >> > > > > >> > Thanks for your indulgence > > > >> > > > > >> > Andy > > > >> > > > > >> > _______________________________________________ > > > >> > Rxtx mailing list > > > >> > Rxtx at qbang.org > > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > > >> > > > > >> > > > >> > > > >> > > > >> -- > > > >> Atte: > > > >> Daniel Dario Morales Salas > > > >> Ingeniero Civil en Computaci?n e Inform?tica > > > >> Tel?fono: 02 684 3417 > > > >> Celular: 09 643 1802 > > > >> Santiago, Chile > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at qbang.org > > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > > > -- > > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > > > WWW: http://www.sharms.org/blog > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From Bob_Jacobsen at lbl.gov Thu Feb 4 09:26:49 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Thu, 4 Feb 2010 08:26:49 -0800 Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 Message-ID: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're using RXTX-2.2pre2, although it emits the known message about "Version mismatch". WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 After the usual messing around, we've got it working on 11 Windows versions, multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ have things working rarely say so, so I don't know whether anybody has gotten it to work on 10.4 or not. The problem encountered is this: dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib dyld: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib followed by the JVM crashing hard. I've got those dump files if that would help. Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If so, is there a patch I can get and build? Thanks Bob -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From tjarvi at qbang.org Thu Feb 4 14:22:21 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 4 Feb 2010 14:22:21 -0700 (MST) Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 In-Reply-To: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> References: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> Message-ID: On Thu, 4 Feb 2010, Bob Jacobsen wrote: > We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're > using RXTX-2.2pre2, although it emits the known message about "Version > mismatch". > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > > After the usual messing around, we've got it working on 11 Windows versions, > multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with > a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ > have things working rarely say so, so I don't know whether anybody has gotten > it to work on 10.4 or not. > > The problem encountered is this: > > dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > dyld: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > followed by the JVM crashing hard. I've got those dump files if that would > help. > > Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If > so, is there a patch I can get and build? > Hi Bob, I talked to a coworker about the problem you ran into. It appears that it is possible to target 'older' Mac systems through makefile configuration changes. "Configuring a Makefile-Based Project If you have a makefile-based project, you can also take advantage of SDK-based development, by adding the appropriate options to your compile and link commands. Using SDKs in makefile-based projects requires GCC 4.0 or later. To choose an SDK, you use the -isysroot option with the compiler and the -syslibroot option with the linker. Both options require that you specify the full path to the desired SDK directory. To set the Deployment OS version in a makefile, use a makefile variable of the form: ENVP= MACOSX_DEPLOYMENT_TARGET=10.4. To use this variable in your makefile, include it in front of your compile and link commands." http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html Or build on the oldest system you want to support. -- Trent Jarvi tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Thu Feb 4 14:56:19 2010 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Thu, 4 Feb 2010 14:56:19 -0700 Subject: [Rxtx] RXTX on 64 Bit Redhat In-Reply-To: References: <4ec9eab61001281448g3dd84910r867619948a4e0d7a@mail.gmail.com> Message-ID: Trent -- Finally fixed all my build related issues. I ran into another issue. On one of my machines my JDK is returning multiple folders for the "java.ext.dirs" (java.ext.dirs -> /opt/jdk1.6.0_17/jre/lib/ext:/usr/java/packages/lib/ext) system property. As a result my JVM wasn't able to detect the gnu.io.rxtx.properties. I am attaching a patch for RXTXCommDriver.java file to check for multiple locations. Also i have to assign permission 660 to all my dev ports to be located by RXTX. Pawan ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 5:12 PM To: Trent Jarvi Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Here is the error i get when i build the src from release-2-1-7 -bash-3.2$ make ( \ \ cd i686-pc-linux-gnu; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/ jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I/opt/jav a1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec - c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialImp.lo;\ if [ "Serial" = "Serial" ]; then \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I /opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_tim espec -c /home/jb_stg/rxtx/rxtx-devel/./src/fuserImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ else \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo; \ fi; \ ) gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/inclu de -I/opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need _timespec -c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -fPIC -DPIC -o /hom e/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/.libs/SerialImp.o /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:25:29: error: gnu_io_RXTXPort.h: No such file or directory In file included from /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:113: /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:91: error: expected specifier-qua lifier-list before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'jobject' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:408: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:409: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:410: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:411: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:415: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:416: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:417: error: expected '=', ',', '; ', 'asm' or '__attribute__' before 'is_interrupted' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:418: error: expected declaration specifiers or '...' before 'jint' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:424: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:441: error: expected ')' before ' *' token ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 4:57 PM To: Santosh Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Santosh -- Thank you. That fixed the issue. All -- What CVS branch or release should i use to get the latest RXTX src code. Pawan ________________________________ From: Santosh [mailto:santosh.ry at gmail.com] Sent: Thursday, January 28, 2010 3:49 PM To: Kharbanda, Pawan Cc: Trent Jarvi; rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat error "./configure: /bin/sh^M: bad interpreter: No such file or directory". I think you need to run dos2unix on script files before compiling. Thanks, Santosh On Thu, Jan 28, 2010 at 5:33 PM, Kharbanda, Pawan > wrote: Trent -- We are upgrading our exisiting OS and JDK on a project that rely heavily on RXTX api's. We are now using JDK1.6 32 bit (build 1.6.0_17-b04) and RedHat 5 on a 64 bit machine. Linux tocrhstg02.dot.state.co.us 2.6.18-164.6.1.el5 #1 SMP Tue Oct 27 11:30:06 EDT 2009 i686 i686 i386 GNU/Linux Red Hat Enterprise Linux Server release 5.4 (Tikanga) I tried to run version 2.1.7 r2 on it but not able to see any of my Digi ports I was able to access only /dev/ttyS0 (physical ports). Not sure if the problem is with the Digi driver or RXTX. I tried to open a Digi port with minicom and it worked fine. I also tried to get latest from CVS (rxtx-devel) and when I do "configure" I see this error "./configure: /bin/sh^M: bad interpreter: No such file or directory". Can someone please help me with this? Thanks for the help. Pawan _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch.txt URL: From juan.vicente.l.g at gmail.com Sat Feb 13 04:44:17 2010 From: juan.vicente.l.g at gmail.com (Juan Vicente Lopez Gutierrez) Date: Sat, 13 Feb 2010 12:44:17 +0100 Subject: [Rxtx] RXTX in macmini OSX 10.5 Message-ID: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> Hello. My name is Juanvi and I'm from Spain. I tried to launch a software created by me in the library CXR java to send information through the serial port and I can not make it work. In windows if I've done but not mac. I have a mac mini with OSX 10.5 and have read in the list of web mail that you CXR if you have managed to make it work on that operating system. I need you help me please. Do I make the mistake that shows me java: run: Stable Library =============================== Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 gnu.io.PortInUseException: Unknow Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:26) at TwoWatSerialComm.main(TwoWaySerialComm.java:106) Experimental: JNI_OnLoad called. GENERACION CORRECTA (total time: 0 seconds) I do not have permission to access the serial port, do not know. Os agradeceria much to sit down. A greeting and thanks. Pardon my English. Juanvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From juan.vicente.l.g at gmail.com Sat Feb 13 14:39:41 2010 From: juan.vicente.l.g at gmail.com (Juan Vicente Lopez Gutierrez) Date: Sat, 13 Feb 2010 22:39:41 +0100 Subject: [Rxtx] Fwd: RXTX in macmini OSX 10.5 In-Reply-To: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> References: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> Message-ID: <29405e5c1002131339m2059d169sdc8549ed9706a1af@mail.gmail.com> ---------- Forwarded message ---------- From: Juan Vicente Lopez Gutierrez Date: 2010/2/13 Subject: RXTX in macmini OSX 10.5 To: rxtx at qbang.org Hello. My name is Juanvi and I'm from Spain. I tried to launch a software created by me in the library CXR java to send information through the serial port and I can not make it work. In windows if I've done but not mac. I have a mac mini with OSX 10.5 and have read in the list of web mail that you CXR if you have managed to make it work on that operating system. I need you help me please. Do I make the mistake that shows me java: run: Stable Library =============================== Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 gnu.io.PortInUseException: Unknow Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:26) at TwoWatSerialComm.main(TwoWaySerialComm.java:106) Experimental: JNI_OnLoad called. GENERACION CORRECTA (total time: 0 seconds) I do not have permission to access the serial port, do not know. Os agradeceria much to sit down. A greeting and thanks. Pardon my English. Juanvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Mon Feb 22 04:35:48 2010 From: george.dma at gmail.com (George H) Date: Mon, 22 Feb 2010 13:35:48 +0200 Subject: [Rxtx] Lingering rxtx process Message-ID: Hi, I am using RXTX v2.1-7. I use it to communicate with 2 serial receipt printers and 1 serial line display device. My program runs well using the RXTX library on Windows and Linux. But... when I installed Linux on another hardware the program does not exit properly. By this I mean that the java program seems to have exited (passed the System.exit(0)) code but the console still does not return to the bash shell. I have to CTRL+C each time to kill the program. And on each restart RXTX has to remove stale LCK files. Just note I am only getting this on one machine, if it makes any difference it is an i686 system with all VIA chipsets and VIA-C7M NannoBGA2 processor. Any ideas? Thanks -- George H george.dma at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Mon Feb 22 04:43:43 2010 From: george.dma at gmail.com (George H) Date: Mon, 22 Feb 2010 13:43:43 +0200 Subject: [Rxtx] Lingering rxtx process Message-ID: Hi, I am using RXTX v2.1-7. I use it to communicate with 2 serial receipt printers and 1 serial line display device. My program runs well using the RXTX library on Windows and Linux. But... when I installed Linux on another hardware the program does not exit properly. By this I mean that the java program seems to have exited (passed the System.exit(0)) code but the console still does not return to the bash shell. I have to CTRL+C each time to kill the program. And on each restart RXTX has to remove stale LCK files. Just note I am only getting this on one machine, if it makes any difference it is an i686 system with all VIA chipsets and VIA-C7M NannoBGA2 processor. Any ideas? Thanks -- George H george.dma at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Tue Feb 23 01:29:42 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Tue, 23 Feb 2010 09:29:42 +0100 Subject: [Rxtx] Lingering rxtx process In-Reply-To: References: Message-ID: <73a89f361002230029w4a9ec14bt56d654e43c1c9623@mail.gmail.com> 2010/2/22 George H > Hi, > > I am using RXTX v2.1-7. > I use it to communicate with 2 serial receipt printers and 1 serial line > display device. My program runs well using the RXTX library on Windows and > Linux. > But... when I installed Linux on another hardware the program does not exit > properly. By this I mean that the java program seems to have exited (passed > the System.exit(0)) code but the console still does not return to the bash > shell. > > Thread in Noember 2009' - http://mailman.qbang.org/pipermail/rxtx/2009-November/5778408.html I have disocvered one technique which solved this problem in Linux Ubuntu and Mac for RXTX pre2.2, but should helps in 2.1.7 as well. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 01:02:21 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 13:32:21 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> My serial port driver(apparently) does not support receive timeout.I registered an event listener for DATA_AVAILABLE. However, the control never seems to come out of the 'while' loop.Shouldn't the InputStream.read return a '-1' immediately if no data is available (this seems to be the default operation)? This was tried on a x86 Linux desktop using rxtx-2.1-7 I've added the snippet for clarity: /******************************************************************************************************************************************************************************/ mySerialPort.enableReceiveThreshold(2000);//Trying to set a time limit for read calls System.out.println(mySerialPort.isReceiveTimeoutEnabled()); // I get FALSE, so its not supported on hardware. mySerialPort.addEventListener(this); mySerialPort.notifyOnDataAvailable(true);//register a event with //my SerialEvent listener implementation: public void serialEvent(SerialPortEvent arg0) { int newData=0; switch(arg0.getEventType()){ case SerialPortEvent.DATA_AVAILABLE: while (newData != -1) { try { newData = is.read();//This should eventually return a -1 if no data is available within a timeout.PROBLEM!! System.out.println("Got a byte from port:"+newData); if (newData == -1) { break; } } catch (IOException ex) { System.err.println(ex); return; } } break; } return; } /******************************************************************************************************************************************************************************/ Thanks and regards, Ravi From michael.erskine at ketech.com Wed Feb 3 02:26:50 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 09:26:50 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From michael.erskine at ketech.com Wed Feb 3 05:03:30 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 12:03:30 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > Michael Erskine > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > > Your event handler should handle the event and return immediately so that its > controlling thread can handle other events. I recommend a single read in the > following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) > reads all available bytes up to the size of the buffer returning the number of > bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } After posting this I considered the glaring possibility of the rawbuf read buffer being too small to receive all the available bytes and perhaps skipping data: after all, I'm guessing that is why we see so many posts asking for help with blocking implementations of read event handlers looping on "while(bytes are available)". I've spent this morning writing an extensive multi-threaded unit test suite that includes tests with a tiny buffer compared to the amount of data available and found that no data was being skipped. I now want to know why! The SerialPortEvent.DATA_AVAILABLE event must be being fired again if there is more data available on the input stream. If that is the case then it should be heavily documented with good examples in the wiki to avoid the types of developer anguish we see so regularly. BTW: I'm not at liberty to post the JUnit tests as they use my company's unit test suite framework. Regards, Michael Erskine. From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 06:18:04 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 18:48:04 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Hello Michael, I tried out your suggestion but the problem is that the read(rawbuf) blocks until the entire length of the rawbuf array has been read (blocking). I cannot decide on a reasonable size of the array because it varies from 2 bytes to as much as 50 byes (i'm communicating with a modem,each response is of a different length), which is why i wanted to use non blocking calls. But on a side note, read(byte[]) in turn calls the read() in a loop.In the native C function, the read is supposed to return a -1 upon timeout.But my driver does not support timeout.The default timeout value is zero and the linux select call upon zero time out causes an infinite wait.What am i missing...... Thanks and regards, Ravi Date: Wed, 3 Feb 2010 09:26:50 +0000 From: Michael Erskine To: "rxtx at qbang.org" Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: Content-Type: text/plain; charset="us-ascii" > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From m.kirkland at comcast.net Wed Feb 3 06:46:03 2010 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 3 Feb 2010 05:46:03 -0800 Subject: [Rxtx] One port blocking another port In-Reply-To: References: Message-ID: <68768633814F4D7D86761D34F0764FE0@bengal.net> It turns out this is caused by having the RTS/CTS flow control turned on and me not providing a true on the RTS pin. Somehow it seems the port timing out on a read allows the write to proceed. This is not an issue for my application but I wonder if the write should not proceed until the RTS pin is true even if a read times out. mk -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Monday, January 25, 2010 7:48 PM To: Mike Kirkland Cc: rxtx at qbang.org Subject: Re: [Rxtx] One port blocking another port On Mon, 25 Jan 2010, Mike Kirkland wrote: > > Hi All, > > ? > > I have a program that reads from one com port and writes to another com > port. It also does the same thing in reverse (reads from the second com port > and writes to the first one. It basically ties two com ports together. > > ? > > One port is very chatty and has a consent stream of data. The other port has > very little data. > > ? > > Both ports use a 5000 ms (5 second) time out. > > ? > > The issue I am having is that is appears that the first port?s write to the > second port is blocked while the second port is waiting for input. The first > port?s write proceeds only after the second port has timed out. > > ? > > I suppose I could have something twisted around in my code but I was > wondering if this is a know issue? > Hi Kirk, I've not seen a report like this. Perhaps some simple reproduction code will reveal a problem on your end or help us identify a problem in rxtx. I think there are several users doing multiport communication. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Wed Feb 3 07:03:58 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:03:58 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Message-ID: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> 2010/2/3 Ravishankar N > Hello Michael, > [..] > But on a side note, read(byte[]) in turn calls the read() in a loop.In the > native C function, the read is supposed to return a -1 upon timeout.But my > driver > does not support timeout.The default timeout value is zero and the linux > select call upon zero time out causes an infinite wait.What am i > missing...... > > When I have tested RXTX between platforms, I have observed "hangup" inside JNI driver when no data in Linux, is normal thing. Solution was setting the timeout for RXTX when no data from JNI driver. Something like that: commPort.enableReceiveTimeout(10); And it works perfect.... The only difference is that I am NOT using events - I am using continous read in separate thread and if data is available, is parsed and transferred to application using exception. Regards Mariusz > Thanks and regards, > Ravi > > Date: Wed, 3 Feb 2010 09:26:50 +0000 > From: Michael Erskine > To: "rxtx at qbang.org" > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > Message-ID: > > > Content-Type: text/plain; charset="us-ascii" > > > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of > > Ravishankar N > > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > > > My serial port driver(apparently) does not support receive timeout.I > > registered an event listener for DATA_AVAILABLE. However, the control > never > > seems to come out of the 'while' loop.Shouldn't the > > InputStream.read return a '-1' immediately if no data is available (this > seems > > to be the default operation)? > > Your event handler should handle the event and return immediately so that > its controlling thread can handle other events. I recommend a single read in > the following manner: rawbuf is a byte[] of "reasonable" size and the > read(byte[]) reads all available bytes up to the size of the buffer > returning the number of bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } > > This style of reading has worked for me with RXTX on Linux and Windows XP > for a good few years now in railway industry communications systems. Any > timeouts (largely unnecessary in my applications) can be handled elsewhere, > usually at a higher layer. > > Regards, > Michael Erskine. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Feb 3 07:22:55 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 3 Feb 2010 09:22:55 -0500 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: I'm guessing that this is driver specific. I recently had to support a select()/poll() infrastructure for a linux serial DD, its certainly non trivial to support async IO, so I suspect the problem in this case has to do with missing poll infrastructure in the device driver. This also has to coupled with special open flags for the device (which is within the rxtx code) The key routines within a 2.6 kernel linux device driver are shown below (if you have access to it for your particular device) are indicated below (here is a snippet from my device driver c code that supports polling/select). User space code to test this shown below also, note that the device needs to be opened with the O_NONBLOCK option to support the select/poll api // device driver code ..... /* * File operations supported by this driver. */ static struct file_operations iop_fops = { .owner = THIS_MODULE, .check_flags= iop_check_flags, .ioctl = iop_ioctl, .open = iop_open, .poll = iop_poll, // SUPPORT FOR SELECT/POLL infrastructure .read = iop_read, .release = iop_release, .write = iop_write, }; /** * Select/poll/epoll infrastructure. * * @param file * @param wait * * @return */ static unsigned int iop_poll(struct file *filp, poll_table *wait) { struct iop_device *devp = (struct iop_device *)filp->private_data; // the poll_table wait arg is an opaque pointer poll_wait(filp, &devp->readq, wait); // return from poll indicating whether we have read/write data unsigned int mask = 0; if (kfifo_len(devp->rx_fifo)) { mask |= (POLLIN | POLLRDNORM); } // @JC We don't do select on write yet // if (kfifo_len(devp->tx_fifo)) { // mask |= (POLLOUT | POLLWRNORM); // } // Only print out while debugging // if (mask != 0) { // printk (KERN_INFO "%s: [%04x]\n", __FUNCTION__, mask); // } return mask; } /** * device driver blocking and non blocking read function. This * function reads the requested number of bytes from the read * kfifo blocking as required. * * @param filp * @param buf * @param count * @param f_pos * * @return */ static ssize_t iop_read(struct file *filp, char __user *buf, size_t count, loff_t * ppos) { // access appropriate device struct struct iop_device *devp = (struct iop_device *) filp->private_data; ssize_t retval; // support non blocking mode (default) by checking if the kfifo is empty first if ((kfifo_len(devp->rx_fifo)==0) && (filp->f_flags & O_NONBLOCK)) { return -EAGAIN; } // wait for rx_fifo to receive data via receive interrupts retval = wait_event_interruptible(devp->readq, kfifo_len(devp->rx_fifo) != 0); // check for some error condition if (retval) { printk (KERN_ERR "%s: wait_event_interruptible returned[%d]\n", __FUNCTION__, retval); return retval; } // copy max requested bytes from rx_fifo to device buffer // this may still leave bytes in the kfifo for a subsequent read // if we are reading in a loop retval = kfifo_get(devp->rx_fifo, devp->rxbuf, count); // printk (KERN_INFO "%s: [%d] byte(s)\n", __FUNCTION__, retval); if (copy_to_user(buf, devp->rxbuf, retval)) { printk (KERN_ERR "%s: problem copying rx_fifo data to user buffer\n", __FUNCTION__); return -EFAULT; } return retval; } // a selection of my user space code reading via select()/poll()..... // user space open code iop_fd = ::open( deviceName.data(), O_RDWR | O_NONBLOCK); while ((bytes_to_expect - bytes_read) > 0) { // must reinitialize these between select calls fd_set readfds; FD_ZERO( &readfds ); FD_SET( iop_fd, &readfds ); // 1s sec read polling timeout struct timeval timeout; timeout.tv_sec = 1; timeout.tv_usec = 0; int rc = select( FD_SETSIZE, &readfds, NULL, NULL, &timeout ); // read from file when descriptor // indicates data available without blocking if ((rc > 0) && FD_ISSET(iop_fd, &readfds)) { // read into the appropriate offset within the rx_buf int temp = read(iop_fd, rx_buf + bytes_read, bytes_to_expect - bytes_read); if (!temp) { printf("EOF detected with %d bytes expected\n", bytes_to_expect - bytes_read); } else { bytes_read += temp; } } else if (rc < 0){ printf("%s: select on [%s], bytes_read[%d], errno=%d\n", __FUNCTION__, thread_args->device, bytes_read, errno); } else { printf("%s: select on [%s], bytes_read[%d], timeout\n", __FUNCTION__, thread_args->device, bytes_read); } } On Wed, Feb 3, 2010 at 9:03 AM, Mariusz Dec wrote: > > > 2010/2/3 Ravishankar N > >> Hello Michael, >> [..] >> >> But on a side note, read(byte[]) in turn calls the read() in a loop.In the >> native C function, the read is supposed to return a -1 upon timeout.But my >> driver >> does not support timeout.The default timeout value is zero and the linux >> select call upon zero time out causes an infinite wait.What am i >> missing...... >> >> > When I have tested RXTX between platforms, I have observed "hangup" inside > JNI driver when no data in Linux, is normal thing. > > Solution was setting the timeout for RXTX when no data from JNI driver. > > Something like that: > > commPort.enableReceiveTimeout(10); > > And it works perfect.... > > The only difference is that I am NOT using events - I am using continous > read in separate thread and if data is available, is parsed and transferred > to application using exception. > > Regards > Mariusz > > > >> Thanks and regards, >> Ravi >> >> Date: Wed, 3 Feb 2010 09:26:50 +0000 >> From: Michael Erskine >> To: "rxtx at qbang.org" >> Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? >> Message-ID: >> >> >> Content-Type: text/plain; charset="us-ascii" >> >> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >> Of >> > Ravishankar N >> > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? >> > >> > My serial port driver(apparently) does not support receive timeout.I >> > registered an event listener for DATA_AVAILABLE. However, the control >> never >> > seems to come out of the 'while' loop.Shouldn't the >> > InputStream.read return a '-1' immediately if no data is available (this >> seems >> > to be the default operation)? >> >> Your event handler should handle the event and return immediately so that >> its controlling thread can handle other events. I recommend a single read in >> the following manner: rawbuf is a byte[] of "reasonable" size and the >> read(byte[]) reads all available bytes up to the size of the buffer >> returning the number of bytes actually read... >> >> case SerialPortEvent.DATA_AVAILABLE: >> try { >> int i = is.read(rawbuf); >> if (i == -1) { >> << process EOF condition - should never happen >> >> return; >> } >> << process bytes (rawbuf, i); >> >> return; >> } catch (IOException e) { >> << promptly deal with exception >> >> return; >> } >> >> This style of reading has worked for me with RXTX on Linux and Windows XP >> for a good few years now in railway industry communications systems. Any >> timeouts (largely unnecessary in my applications) can be handled elsewhere, >> usually at a higher layer. >> >> Regards, >> Michael Erskine. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Feb 3 07:33:27 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:33:27 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: <73a89f361002030633j682610afia48dc7accd8e049b@mail.gmail.com> 2010/2/3 John Coffey > I'm guessing that this is driver specific. I recently had to support a > select()/poll() infrastructure for a linux serial DD, its certainly non > trivial to support async IO, so I suspect the problem in this case has to do > with missing poll infrastructure in the device driver. This also has to > coupled with special open flags for the device (which is within the rxtx > code) > > Yes, you are right, it may be driver specific, but in my case I haven't changed blocking JNI driver. I have added ONLY one call to RXTX method mentioned in my previous post and blocking (as seen as from Java app) gone out... Maybe this is not elegant, but works without problem in my app. I am using only FTDI chips and their drivers from couple of years and maybe this is the kind of the way to have no many problems with serial as well? Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From andyrxtx at g0poy.co.uk Wed Feb 3 11:09:04 2010 From: andyrxtx at g0poy.co.uk (andyrxtx at g0poy.co.uk) Date: Wed, 3 Feb 2010 18:09:04 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes Message-ID: <20100203180904.164f24dd@workstation.site> ?Hello RXTX group, I have just joined this group, and this is my first posting. I wanted to pass on some information regarding rxtx, so apologies if this has been brought up before. I have searched back through the archives but nothing specific came up. I am not a Java programmer, and I only came across rxtx a few days ago. I use a piece of test equipment called a miniVNA http://www.miniradiosolutions.com/ This is a serial USB controlled instrument, and it has control software available for MS windows, and a very old and now non-working Linux application. A few days ago Dietmar, DL2SBA released a Java application to control the miniVNA, obviously this application makes use of rxtx. The program worked fine on Windows, so I set about installing it onto Linux. I use SUSE11.1 After a few false starts, I got the system running fairly easily, sorting out the file locking by adding the uucp group to the users account as suggested (I used the 2.2pre binary files) I then passed the install instructions onto another miniVNA user, who also uses SUSE, but he ran into problems. To cut a long story short, he was also having file lock problems, but the uucp fix did not work. Digging into his system I found that there have been some changes in SUSE 11.2. tty ports are now assigned to the dialout group rather than uucp. A hint in the rxtx INSTALL file, suggested that var/lock needs to be checked, so: SUSE 11.1, var/lock is root:uucp SUSE 11.2 var/lock is root:root A search on Google brought up several comments regarding this, and also a bugzilla entry. https://bugzilla.novell.com/show_bug.cgi?id=552095 However from reading the various posts, some of which are in the bugzilla entry, it appears that many distros may be, or have changed to this configuration, and this will undoubtedly break several things, rxtx included. I solved my fellow SUSE users problem by compiling the rxtx libs with the no lock file option during configure, and that solved his problem. As this issue will probably take some time to get resolved across all the various Linux distros, it might be worth considering changing the default on the Linux build of rxtx not to use lockfiles, or provide the two versions of the lib in the binary archive. Thanks for your indulgence Andy From damorales at gmail.com Wed Feb 3 11:33:23 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 15:33:23 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203180904.164f24dd@workstation.site> References: <20100203180904.164f24dd@workstation.site> Message-ID: Hi I had the same problem in Mandriva 2010 and yes, adding the user to the uucp group did not work as it used to be in earlier versions of linux distros, causing RXTX to not work as non root user. The problem appears because the existense of UDEV, now you MUST add a RULE so the group (uucp or whatever) have access (Read, Write, Execute) to the Serial Port. To solve the problem, without needing to recompile RXTX, you must add a rule to grant permissions (0666) to the group for the device or port (tty*, ttyUSB*, etc). I do not remember now what is the line i added but when i come back home i will give it to you (i am at work now). Greetings ! 2010/2/3 > Hello RXTX group, > > I have just joined this group, and this is my first posting. > I wanted to pass on some information regarding rxtx, so apologies if > this has been brought up before. I have searched back through the > archives but nothing specific came up. > > I am not a Java programmer, and I only came across rxtx a few days ago. > > I use a piece of test equipment called a miniVNA > http://www.miniradiosolutions.com/ > > This is a serial USB controlled instrument, and it has control software > available for MS windows, and a very old and now non-working Linux > application. > > A few days ago Dietmar, DL2SBA released a Java application to control the > miniVNA, obviously this application makes use of rxtx. > > The program worked fine on Windows, so I set about installing it onto > Linux. I use SUSE11.1 After a few false starts, I got the system running > fairly easily, sorting out the file locking by adding the uucp group to > the users account as suggested (I used the 2.2pre binary files) I then > passed the install instructions onto another miniVNA user, who also uses > SUSE, but he ran into problems. To cut a long story short, he was > also having file lock problems, but the uucp fix did not work. Digging > into his system I found that there have been some changes in SUSE 11.2. > > tty ports are now assigned to the dialout group rather than uucp. > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > checked, so: > > SUSE 11.1, var/lock is root:uucp > SUSE 11.2 var/lock is root:root > > A search on Google brought up several comments regarding this, and also > a bugzilla entry. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > However from reading the various posts, some of which are in the bugzilla > entry, it appears that many distros may be, or have changed to this > configuration, and this will undoubtedly break several things, rxtx > included. > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > no lock file option during configure, and that solved his problem. > > As this issue will probably take some time to get resolved across all the > various Linux distros, it might be worth considering changing the default > on the Linux build of rxtx not to use lockfiles, or provide the two > versions of the lib in the binary archive. > > Thanks for your indulgence > > Andy > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Wed Feb 3 12:07:02 2010 From: andy at g0poy.com (Andy Eskelson) Date: Wed, 3 Feb 2010 19:07:02 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> Message-ID: <20100203190702.1b0e7015@workstation.site> Thanks Daniel, I am aware of the permissions problem, I have had a udev rules to solve this for other programs for some time. . I don't think that this is the same problem. as far as I can understand things, the lock files are written in var/lock. Previously var/lock and dev/tty-whatever were the same group. Now with var/lock owned by and with a group of root:root anything other than root cannot create a lock file. Even minicom is broken by this change. This change is going to have quite a few knock-on effects I think. Andy On Wed, 3 Feb 2010 15:33:23 -0300 Daniel Morales Salas wrote: > Hi > > I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > group did not work as it used to be in earlier versions of linux distros, > causing RXTX to not work as non root user. > > The problem appears because the existense of UDEV, now you MUST add a RULE > so the group (uucp or whatever) have access (Read, Write, Execute) to the > Serial Port. > > To solve the problem, without needing to recompile RXTX, you must add a rule > to grant permissions (0666) to the group for the device or port (tty*, > ttyUSB*, etc). I do not remember now what is the line i added but when i > come back home i will give it to you (i am at work now). > > Greetings ! > > 2010/2/3 > > > Hello RXTX group, > > > > I have just joined this group, and this is my first posting. > > I wanted to pass on some information regarding rxtx, so apologies if > > this has been brought up before. I have searched back through the > > archives but nothing specific came up. > > > > I am not a Java programmer, and I only came across rxtx a few days ago. > > > > I use a piece of test equipment called a miniVNA > > http://www.miniradiosolutions.com/ > > > > This is a serial USB controlled instrument, and it has control software > > available for MS windows, and a very old and now non-working Linux > > application. > > > > A few days ago Dietmar, DL2SBA released a Java application to control the > > miniVNA, obviously this application makes use of rxtx. > > > > The program worked fine on Windows, so I set about installing it onto > > Linux. I use SUSE11.1 After a few false starts, I got the system running > > fairly easily, sorting out the file locking by adding the uucp group to > > the users account as suggested (I used the 2.2pre binary files) I then > > passed the install instructions onto another miniVNA user, who also uses > > SUSE, but he ran into problems. To cut a long story short, he was > > also having file lock problems, but the uucp fix did not work. Digging > > into his system I found that there have been some changes in SUSE 11.2. > > > > tty ports are now assigned to the dialout group rather than uucp. > > > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > checked, so: > > > > SUSE 11.1, var/lock is root:uucp > > SUSE 11.2 var/lock is root:root > > > > A search on Google brought up several comments regarding this, and also > > a bugzilla entry. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > However from reading the various posts, some of which are in the bugzilla > > entry, it appears that many distros may be, or have changed to this > > configuration, and this will undoubtedly break several things, rxtx > > included. > > > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > > no lock file option during configure, and that solved his problem. > > > > As this issue will probably take some time to get resolved across all the > > various Linux distros, it might be worth considering changing the default > > on the Linux build of rxtx not to use lockfiles, or provide the two > > versions of the lib in the binary archive. > > > > Thanks for your indulgence > > > > Andy > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From thisdyingdream at gmail.com Wed Feb 3 12:32:35 2010 From: thisdyingdream at gmail.com (Steven Harms) Date: Wed, 3 Feb 2010 14:32:35 -0500 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203190702.1b0e7015@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: This is currently a bug in OpenSUSE that affects more than just rxtx, and is a result of unified udev rules. You can work around this by making udev change the group back to uucp until something more happens. https://bugzilla.novell.com/show_bug.cgi?id=552095 Thanks, Steve On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > Thanks Daniel, > > I am aware of the permissions problem, I have had a udev rules to solve > this for other programs for some time. > . > I don't think that this is the same problem. as far as I can understand > things, the lock files are written in var/lock. Previously var/lock and > dev/tty-whatever were the same group. Now with var/lock owned by and with > a group of root:root anything other than root cannot create a lock > file. Even minicom is broken by this change. > > This change is going to have quite a few knock-on effects I think. > > > Andy > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > Daniel Morales Salas wrote: > >> Hi >> >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp >> group did not work as it used to be in earlier versions of linux distros, >> causing RXTX to not work as non root user. >> >> The problem appears because the existense of UDEV, now you MUST add a RULE >> so the group (uucp or whatever) have access (Read, Write, Execute) to the >> Serial Port. >> >> To solve the problem, without needing to recompile RXTX, you must add a rule >> to grant permissions (0666) to the group for the device or port (tty*, >> ttyUSB*, etc). I do not remember now what is the line i added but when i >> come back home i will give it to you (i am at work now). >> >> Greetings ! >> >> 2010/2/3 >> >> > Hello RXTX group, >> > >> > I have just joined this group, and this is my first posting. >> > I wanted to pass on ?some information regarding rxtx, so apologies if >> > this has been brought up before. I have searched back through the >> > archives but nothing specific came up. >> > >> > I am not a Java programmer, and I only came across rxtx a few days ago. >> > >> > I use a piece of test equipment called a miniVNA >> > http://www.miniradiosolutions.com/ >> > >> > This is a serial USB controlled instrument, and it has control software >> > available for MS windows, and a very old and now non-working Linux >> > application. >> > >> > A few days ago Dietmar, DL2SBA released a Java application to control the >> > miniVNA, obviously this application makes use of rxtx. >> > >> > The program worked fine on Windows, so I set about installing it onto >> > Linux. I use SUSE11.1 After a few false starts, I got the system running >> > fairly easily, sorting out the file locking by adding the uucp group to >> > the users account as suggested (I used the 2.2pre binary files) I then >> > passed the install instructions onto another miniVNA user, who also uses >> > SUSE, but he ran into problems. To cut a long story short, he was >> > also having file lock problems, but the uucp fix did not work. Digging >> > into his system I found that there have been some changes in SUSE 11.2. >> > >> > tty ports are now assigned to the dialout group rather than uucp. >> > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be >> > checked, so: >> > >> > SUSE 11.1, var/lock is root:uucp >> > SUSE 11.2 var/lock is root:root >> > >> > A search on Google brought up several comments regarding this, and also >> > a ?bugzilla entry. >> > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 >> > >> > However from reading the various posts, some of which are in the bugzilla >> > entry, it appears that many distros may be, or have changed to this >> > configuration, and this will undoubtedly break several things, rxtx >> > included. >> > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the >> > no lock file option during configure, and that solved his problem. >> > >> > As this issue will probably take some time to get resolved across all the >> > various Linux distros, it might be worth considering changing the default >> > on the Linux build of rxtx not to use lockfiles, or provide the two >> > versions of the lib in the binary archive. >> > >> > Thanks for your indulgence >> > >> > Andy >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> >> >> >> -- >> Atte: >> Daniel Dario Morales Salas >> Ingeniero Civil en Computaci?n e Inform?tica >> Tel?fono: 02 684 3417 >> Celular: 09 643 1802 >> Santiago, Chile > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 WWW: http://www.sharms.org/blog From andy at g0poy.com Wed Feb 3 17:58:29 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 00:58:29 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: <20100204005829.7dc944e1@workstation.site> Thanks Steve, changing the serial ports back the uucp is not a big problem. I have a udev rule that can be easily modified already. However I cannot see any way of dealing with the var/lock problem apart from making it writable to all. Any thoughts? Andy On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms wrote: > This is currently a bug in OpenSUSE that affects more than just rxtx, > and is a result of unified udev rules. You can work around this by > making udev change the group back to uucp until something more > happens. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > Thanks, > > Steve > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > Thanks Daniel, > > > > I am aware of the permissions problem, I have had a udev rules to solve > > this for other programs for some time. > > . > > I don't think that this is the same problem. as far as I can understand > > things, the lock files are written in var/lock. Previously var/lock and > > dev/tty-whatever were the same group. Now with var/lock owned by and with > > a group of root:root anything other than root cannot create a lock > > file. Even minicom is broken by this change. > > > > This change is going to have quite a few knock-on effects I think. > > > > > > Andy > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > Daniel Morales Salas wrote: > > > >> Hi > >> > >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > >> group did not work as it used to be in earlier versions of linux distros, > >> causing RXTX to not work as non root user. > >> > >> The problem appears because the existense of UDEV, now you MUST add a RULE > >> so the group (uucp or whatever) have access (Read, Write, Execute) to the > >> Serial Port. > >> > >> To solve the problem, without needing to recompile RXTX, you must add a rule > >> to grant permissions (0666) to the group for the device or port (tty*, > >> ttyUSB*, etc). I do not remember now what is the line i added but when i > >> come back home i will give it to you (i am at work now). > >> > >> Greetings ! > >> > >> 2010/2/3 > >> > >> > Hello RXTX group, > >> > > >> > I have just joined this group, and this is my first posting. > >> > I wanted to pass on ?some information regarding rxtx, so apologies if > >> > this has been brought up before. I have searched back through the > >> > archives but nothing specific came up. > >> > > >> > I am not a Java programmer, and I only came across rxtx a few days ago. > >> > > >> > I use a piece of test equipment called a miniVNA > >> > http://www.miniradiosolutions.com/ > >> > > >> > This is a serial USB controlled instrument, and it has control software > >> > available for MS windows, and a very old and now non-working Linux > >> > application. > >> > > >> > A few days ago Dietmar, DL2SBA released a Java application to control the > >> > miniVNA, obviously this application makes use of rxtx. > >> > > >> > The program worked fine on Windows, so I set about installing it onto > >> > Linux. I use SUSE11.1 After a few false starts, I got the system running > >> > fairly easily, sorting out the file locking by adding the uucp group to > >> > the users account as suggested (I used the 2.2pre binary files) I then > >> > passed the install instructions onto another miniVNA user, who also uses > >> > SUSE, but he ran into problems. To cut a long story short, he was > >> > also having file lock problems, but the uucp fix did not work. Digging > >> > into his system I found that there have been some changes in SUSE 11.2. > >> > > >> > tty ports are now assigned to the dialout group rather than uucp. > >> > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > >> > checked, so: > >> > > >> > SUSE 11.1, var/lock is root:uucp > >> > SUSE 11.2 var/lock is root:root > >> > > >> > A search on Google brought up several comments regarding this, and also > >> > a ?bugzilla entry. > >> > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > >> > > >> > However from reading the various posts, some of which are in the bugzilla > >> > entry, it appears that many distros may be, or have changed to this > >> > configuration, and this will undoubtedly break several things, rxtx > >> > included. > >> > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the > >> > no lock file option during configure, and that solved his problem. > >> > > >> > As this issue will probably take some time to get resolved across all the > >> > various Linux distros, it might be worth considering changing the default > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > >> > versions of the lib in the binary archive. > >> > > >> > Thanks for your indulgence > >> > > >> > Andy > >> > > >> > _______________________________________________ > >> > Rxtx mailing list > >> > Rxtx at qbang.org > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > >> > >> > >> > >> -- > >> Atte: > >> Daniel Dario Morales Salas > >> Ingeniero Civil en Computaci?n e Inform?tica > >> Tel?fono: 02 684 3417 > >> Celular: 09 643 1802 > >> Santiago, Chile > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > WWW: http://www.sharms.org/blog From damorales at gmail.com Wed Feb 3 18:26:38 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 22:26:38 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100204005829.7dc944e1@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: Hello I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva 2010 this is what i get: drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ and i don't have ANY problem with lock files and RXTX in my java software. All i had to do was add this rule to udev: # serial KERNEL=="tty*", GROUP="uucp", MODE="0666" and that was all. Of course my user (metalklesk) is part of uucp group. I did not make /var/lock writable to all users. Greetings ! 2010/2/3 Andy Eskelson > Thanks Steve, > > changing the serial ports back the uucp is not a big problem. I have a > udev rule that can be easily modified already. However I cannot see any > way of dealing with the var/lock problem apart from making it writable to > all. Any thoughts? > > Andy > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > wrote: > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > and is a result of unified udev rules. You can work around this by > > making udev change the group back to uucp until something more > > happens. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > Thanks, > > > > Steve > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > Thanks Daniel, > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > this for other programs for some time. > > > . > > > I don't think that this is the same problem. as far as I can understand > > > things, the lock files are written in var/lock. Previously var/lock and > > > dev/tty-whatever were the same group. Now with var/lock owned by and > with > > > a group of root:root anything other than root cannot create a lock > > > file. Even minicom is broken by this change. > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > Daniel Morales Salas wrote: > > > > > >> Hi > > >> > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > the uucp > > >> group did not work as it used to be in earlier versions of linux > distros, > > >> causing RXTX to not work as non root user. > > >> > > >> The problem appears because the existense of UDEV, now you MUST add a > RULE > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > the > > >> Serial Port. > > >> > > >> To solve the problem, without needing to recompile RXTX, you must add > a rule > > >> to grant permissions (0666) to the group for the device or port (tty*, > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > i > > >> come back home i will give it to you (i am at work now). > > >> > > >> Greetings ! > > >> > > >> 2010/2/3 > > >> > > >> > Hello RXTX group, > > >> > > > >> > I have just joined this group, and this is my first posting. > > >> > I wanted to pass on some information regarding rxtx, so apologies > if > > >> > this has been brought up before. I have searched back through the > > >> > archives but nothing specific came up. > > >> > > > >> > I am not a Java programmer, and I only came across rxtx a few days > ago. > > >> > > > >> > I use a piece of test equipment called a miniVNA > > >> > http://www.miniradiosolutions.com/ > > >> > > > >> > This is a serial USB controlled instrument, and it has control > software > > >> > available for MS windows, and a very old and now non-working Linux > > >> > application. > > >> > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > control the > > >> > miniVNA, obviously this application makes use of rxtx. > > >> > > > >> > The program worked fine on Windows, so I set about installing it > onto > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > running > > >> > fairly easily, sorting out the file locking by adding the uucp group > to > > >> > the users account as suggested (I used the 2.2pre binary files) I > then > > >> > passed the install instructions onto another miniVNA user, who also > uses > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > >> > also having file lock problems, but the uucp fix did not work. > Digging > > >> > into his system I found that there have been some changes in SUSE > 11.2. > > >> > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > >> > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > >> > checked, so: > > >> > > > >> > SUSE 11.1, var/lock is root:uucp > > >> > SUSE 11.2 var/lock is root:root > > >> > > > >> > A search on Google brought up several comments regarding this, and > also > > >> > a bugzilla entry. > > >> > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > >> > > > >> > However from reading the various posts, some of which are in the > bugzilla > > >> > entry, it appears that many distros may be, or have changed to this > > >> > configuration, and this will undoubtedly break several things, rxtx > > >> > included. > > >> > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > with the > > >> > no lock file option during configure, and that solved his problem. > > >> > > > >> > As this issue will probably take some time to get resolved across > all the > > >> > various Linux distros, it might be worth considering changing the > default > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > >> > versions of the lib in the binary archive. > > >> > > > >> > Thanks for your indulgence > > >> > > > >> > Andy > > >> > > > >> > _______________________________________________ > > >> > Rxtx mailing list > > >> > Rxtx at qbang.org > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > >> > > > >> > > >> > > >> > > >> -- > > >> Atte: > > >> Daniel Dario Morales Salas > > >> Ingeniero Civil en Computaci?n e Inform?tica > > >> Tel?fono: 02 684 3417 > > >> Celular: 09 643 1802 > > >> Santiago, Chile > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at qbang.org > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > -- > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > WWW: http://www.sharms.org/blog > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Thu Feb 4 05:31:46 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 12:31:46 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: <20100204123146.6cffeb67@workstation.site> Thank's for the confirmation. Something odd is going on somewhere in SUSE 11.2. I'll have to build up a local SUSE11.2 system to see if I can nail down exactly what is going on. Something is blocking the lockfiles in var/lock. The net is nice, but it's a bit difficult trying to work out what is going on what the machine in question is in Germany and I'm in the UK :-) Andy On Wed, 3 Feb 2010 22:26:38 -0300 Daniel Morales Salas wrote: > Hello > > I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva > 2010 this is what i get: > > drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ > > and i don't have ANY problem with lock files and RXTX in my java software. > All i had to do was add this rule to udev: > > # serial > KERNEL=="tty*", GROUP="uucp", MODE="0666" > > and that was all. Of course my user (metalklesk) is part of uucp group. > I did not make /var/lock writable to all users. > > Greetings ! > > 2010/2/3 Andy Eskelson > > > Thanks Steve, > > > > changing the serial ports back the uucp is not a big problem. I have a > > udev rule that can be easily modified already. However I cannot see any > > way of dealing with the var/lock problem apart from making it writable to > > all. Any thoughts? > > > > Andy > > > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > > wrote: > > > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > > and is a result of unified udev rules. You can work around this by > > > making udev change the group back to uucp until something more > > > happens. > > > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > > > Thanks, > > > > > > Steve > > > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > > Thanks Daniel, > > > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > > this for other programs for some time. > > > > . > > > > I don't think that this is the same problem. as far as I can understand > > > > things, the lock files are written in var/lock. Previously var/lock and > > > > dev/tty-whatever were the same group. Now with var/lock owned by and > > with > > > > a group of root:root anything other than root cannot create a lock > > > > file. Even minicom is broken by this change. > > > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > > Daniel Morales Salas wrote: > > > > > > > >> Hi > > > >> > > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > > the uucp > > > >> group did not work as it used to be in earlier versions of linux > > distros, > > > >> causing RXTX to not work as non root user. > > > >> > > > >> The problem appears because the existense of UDEV, now you MUST add a > > RULE > > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > > the > > > >> Serial Port. > > > >> > > > >> To solve the problem, without needing to recompile RXTX, you must add > > a rule > > > >> to grant permissions (0666) to the group for the device or port (tty*, > > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > > i > > > >> come back home i will give it to you (i am at work now). > > > >> > > > >> Greetings ! > > > >> > > > >> 2010/2/3 > > > >> > > > >> > Hello RXTX group, > > > >> > > > > >> > I have just joined this group, and this is my first posting. > > > >> > I wanted to pass on some information regarding rxtx, so apologies > > if > > > >> > this has been brought up before. I have searched back through the > > > >> > archives but nothing specific came up. > > > >> > > > > >> > I am not a Java programmer, and I only came across rxtx a few days > > ago. > > > >> > > > > >> > I use a piece of test equipment called a miniVNA > > > >> > http://www.miniradiosolutions.com/ > > > >> > > > > >> > This is a serial USB controlled instrument, and it has control > > software > > > >> > available for MS windows, and a very old and now non-working Linux > > > >> > application. > > > >> > > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > > control the > > > >> > miniVNA, obviously this application makes use of rxtx. > > > >> > > > > >> > The program worked fine on Windows, so I set about installing it > > onto > > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > > running > > > >> > fairly easily, sorting out the file locking by adding the uucp group > > to > > > >> > the users account as suggested (I used the 2.2pre binary files) I > > then > > > >> > passed the install instructions onto another miniVNA user, who also > > uses > > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > > >> > also having file lock problems, but the uucp fix did not work. > > Digging > > > >> > into his system I found that there have been some changes in SUSE > > 11.2. > > > >> > > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > > >> > > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > > >> > checked, so: > > > >> > > > > >> > SUSE 11.1, var/lock is root:uucp > > > >> > SUSE 11.2 var/lock is root:root > > > >> > > > > >> > A search on Google brought up several comments regarding this, and > > also > > > >> > a bugzilla entry. > > > >> > > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > >> > > > > >> > However from reading the various posts, some of which are in the > > bugzilla > > > >> > entry, it appears that many distros may be, or have changed to this > > > >> > configuration, and this will undoubtedly break several things, rxtx > > > >> > included. > > > >> > > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > > with the > > > >> > no lock file option during configure, and that solved his problem. > > > >> > > > > >> > As this issue will probably take some time to get resolved across > > all the > > > >> > various Linux distros, it might be worth considering changing the > > default > > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > > >> > versions of the lib in the binary archive. > > > >> > > > > >> > Thanks for your indulgence > > > >> > > > > >> > Andy > > > >> > > > > >> > _______________________________________________ > > > >> > Rxtx mailing list > > > >> > Rxtx at qbang.org > > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > > >> > > > > >> > > > >> > > > >> > > > >> -- > > > >> Atte: > > > >> Daniel Dario Morales Salas > > > >> Ingeniero Civil en Computaci?n e Inform?tica > > > >> Tel?fono: 02 684 3417 > > > >> Celular: 09 643 1802 > > > >> Santiago, Chile > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at qbang.org > > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > > > -- > > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > > > WWW: http://www.sharms.org/blog > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From Bob_Jacobsen at lbl.gov Thu Feb 4 09:26:49 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Thu, 4 Feb 2010 08:26:49 -0800 Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 Message-ID: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're using RXTX-2.2pre2, although it emits the known message about "Version mismatch". WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 After the usual messing around, we've got it working on 11 Windows versions, multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ have things working rarely say so, so I don't know whether anybody has gotten it to work on 10.4 or not. The problem encountered is this: dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib dyld: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib followed by the JVM crashing hard. I've got those dump files if that would help. Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If so, is there a patch I can get and build? Thanks Bob -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From tjarvi at qbang.org Thu Feb 4 14:22:21 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 4 Feb 2010 14:22:21 -0700 (MST) Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 In-Reply-To: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> References: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> Message-ID: On Thu, 4 Feb 2010, Bob Jacobsen wrote: > We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're > using RXTX-2.2pre2, although it emits the known message about "Version > mismatch". > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > > After the usual messing around, we've got it working on 11 Windows versions, > multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with > a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ > have things working rarely say so, so I don't know whether anybody has gotten > it to work on 10.4 or not. > > The problem encountered is this: > > dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > dyld: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > followed by the JVM crashing hard. I've got those dump files if that would > help. > > Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If > so, is there a patch I can get and build? > Hi Bob, I talked to a coworker about the problem you ran into. It appears that it is possible to target 'older' Mac systems through makefile configuration changes. "Configuring a Makefile-Based Project If you have a makefile-based project, you can also take advantage of SDK-based development, by adding the appropriate options to your compile and link commands. Using SDKs in makefile-based projects requires GCC 4.0 or later. To choose an SDK, you use the -isysroot option with the compiler and the -syslibroot option with the linker. Both options require that you specify the full path to the desired SDK directory. To set the Deployment OS version in a makefile, use a makefile variable of the form: ENVP= MACOSX_DEPLOYMENT_TARGET=10.4. To use this variable in your makefile, include it in front of your compile and link commands." http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html Or build on the oldest system you want to support. -- Trent Jarvi tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Thu Feb 4 14:56:19 2010 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Thu, 4 Feb 2010 14:56:19 -0700 Subject: [Rxtx] RXTX on 64 Bit Redhat In-Reply-To: References: <4ec9eab61001281448g3dd84910r867619948a4e0d7a@mail.gmail.com> Message-ID: Trent -- Finally fixed all my build related issues. I ran into another issue. On one of my machines my JDK is returning multiple folders for the "java.ext.dirs" (java.ext.dirs -> /opt/jdk1.6.0_17/jre/lib/ext:/usr/java/packages/lib/ext) system property. As a result my JVM wasn't able to detect the gnu.io.rxtx.properties. I am attaching a patch for RXTXCommDriver.java file to check for multiple locations. Also i have to assign permission 660 to all my dev ports to be located by RXTX. Pawan ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 5:12 PM To: Trent Jarvi Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Here is the error i get when i build the src from release-2-1-7 -bash-3.2$ make ( \ \ cd i686-pc-linux-gnu; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/ jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I/opt/jav a1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec - c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialImp.lo;\ if [ "Serial" = "Serial" ]; then \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I /opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_tim espec -c /home/jb_stg/rxtx/rxtx-devel/./src/fuserImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ else \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo; \ fi; \ ) gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/inclu de -I/opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need _timespec -c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -fPIC -DPIC -o /hom e/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/.libs/SerialImp.o /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:25:29: error: gnu_io_RXTXPort.h: No such file or directory In file included from /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:113: /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:91: error: expected specifier-qua lifier-list before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'jobject' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:408: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:409: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:410: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:411: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:415: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:416: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:417: error: expected '=', ',', '; ', 'asm' or '__attribute__' before 'is_interrupted' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:418: error: expected declaration specifiers or '...' before 'jint' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:424: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:441: error: expected ')' before ' *' token ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 4:57 PM To: Santosh Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Santosh -- Thank you. That fixed the issue. All -- What CVS branch or release should i use to get the latest RXTX src code. Pawan ________________________________ From: Santosh [mailto:santosh.ry at gmail.com] Sent: Thursday, January 28, 2010 3:49 PM To: Kharbanda, Pawan Cc: Trent Jarvi; rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat error "./configure: /bin/sh^M: bad interpreter: No such file or directory". I think you need to run dos2unix on script files before compiling. Thanks, Santosh On Thu, Jan 28, 2010 at 5:33 PM, Kharbanda, Pawan > wrote: Trent -- We are upgrading our exisiting OS and JDK on a project that rely heavily on RXTX api's. We are now using JDK1.6 32 bit (build 1.6.0_17-b04) and RedHat 5 on a 64 bit machine. Linux tocrhstg02.dot.state.co.us 2.6.18-164.6.1.el5 #1 SMP Tue Oct 27 11:30:06 EDT 2009 i686 i686 i386 GNU/Linux Red Hat Enterprise Linux Server release 5.4 (Tikanga) I tried to run version 2.1.7 r2 on it but not able to see any of my Digi ports I was able to access only /dev/ttyS0 (physical ports). Not sure if the problem is with the Digi driver or RXTX. I tried to open a Digi port with minicom and it worked fine. I also tried to get latest from CVS (rxtx-devel) and when I do "configure" I see this error "./configure: /bin/sh^M: bad interpreter: No such file or directory". Can someone please help me with this? Thanks for the help. Pawan _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch.txt URL: From juan.vicente.l.g at gmail.com Sat Feb 13 04:44:17 2010 From: juan.vicente.l.g at gmail.com (Juan Vicente Lopez Gutierrez) Date: Sat, 13 Feb 2010 12:44:17 +0100 Subject: [Rxtx] RXTX in macmini OSX 10.5 Message-ID: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> Hello. My name is Juanvi and I'm from Spain. I tried to launch a software created by me in the library CXR java to send information through the serial port and I can not make it work. In windows if I've done but not mac. I have a mac mini with OSX 10.5 and have read in the list of web mail that you CXR if you have managed to make it work on that operating system. I need you help me please. Do I make the mistake that shows me java: run: Stable Library =============================== Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 gnu.io.PortInUseException: Unknow Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:26) at TwoWatSerialComm.main(TwoWaySerialComm.java:106) Experimental: JNI_OnLoad called. GENERACION CORRECTA (total time: 0 seconds) I do not have permission to access the serial port, do not know. Os agradeceria much to sit down. A greeting and thanks. Pardon my English. Juanvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From juan.vicente.l.g at gmail.com Sat Feb 13 14:39:41 2010 From: juan.vicente.l.g at gmail.com (Juan Vicente Lopez Gutierrez) Date: Sat, 13 Feb 2010 22:39:41 +0100 Subject: [Rxtx] Fwd: RXTX in macmini OSX 10.5 In-Reply-To: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> References: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> Message-ID: <29405e5c1002131339m2059d169sdc8549ed9706a1af@mail.gmail.com> ---------- Forwarded message ---------- From: Juan Vicente Lopez Gutierrez Date: 2010/2/13 Subject: RXTX in macmini OSX 10.5 To: rxtx at qbang.org Hello. My name is Juanvi and I'm from Spain. I tried to launch a software created by me in the library CXR java to send information through the serial port and I can not make it work. In windows if I've done but not mac. I have a mac mini with OSX 10.5 and have read in the list of web mail that you CXR if you have managed to make it work on that operating system. I need you help me please. Do I make the mistake that shows me java: run: Stable Library =============================== Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 gnu.io.PortInUseException: Unknow Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:26) at TwoWatSerialComm.main(TwoWaySerialComm.java:106) Experimental: JNI_OnLoad called. GENERACION CORRECTA (total time: 0 seconds) I do not have permission to access the serial port, do not know. Os agradeceria much to sit down. A greeting and thanks. Pardon my English. Juanvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Mon Feb 22 04:35:48 2010 From: george.dma at gmail.com (George H) Date: Mon, 22 Feb 2010 13:35:48 +0200 Subject: [Rxtx] Lingering rxtx process Message-ID: Hi, I am using RXTX v2.1-7. I use it to communicate with 2 serial receipt printers and 1 serial line display device. My program runs well using the RXTX library on Windows and Linux. But... when I installed Linux on another hardware the program does not exit properly. By this I mean that the java program seems to have exited (passed the System.exit(0)) code but the console still does not return to the bash shell. I have to CTRL+C each time to kill the program. And on each restart RXTX has to remove stale LCK files. Just note I am only getting this on one machine, if it makes any difference it is an i686 system with all VIA chipsets and VIA-C7M NannoBGA2 processor. Any ideas? Thanks -- George H george.dma at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Mon Feb 22 04:43:43 2010 From: george.dma at gmail.com (George H) Date: Mon, 22 Feb 2010 13:43:43 +0200 Subject: [Rxtx] Lingering rxtx process Message-ID: Hi, I am using RXTX v2.1-7. I use it to communicate with 2 serial receipt printers and 1 serial line display device. My program runs well using the RXTX library on Windows and Linux. But... when I installed Linux on another hardware the program does not exit properly. By this I mean that the java program seems to have exited (passed the System.exit(0)) code but the console still does not return to the bash shell. I have to CTRL+C each time to kill the program. And on each restart RXTX has to remove stale LCK files. Just note I am only getting this on one machine, if it makes any difference it is an i686 system with all VIA chipsets and VIA-C7M NannoBGA2 processor. Any ideas? Thanks -- George H george.dma at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Tue Feb 23 01:29:42 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Tue, 23 Feb 2010 09:29:42 +0100 Subject: [Rxtx] Lingering rxtx process In-Reply-To: References: Message-ID: <73a89f361002230029w4a9ec14bt56d654e43c1c9623@mail.gmail.com> 2010/2/22 George H > Hi, > > I am using RXTX v2.1-7. > I use it to communicate with 2 serial receipt printers and 1 serial line > display device. My program runs well using the RXTX library on Windows and > Linux. > But... when I installed Linux on another hardware the program does not exit > properly. By this I mean that the java program seems to have exited (passed > the System.exit(0)) code but the console still does not return to the bash > shell. > > Thread in Noember 2009' - http://mailman.qbang.org/pipermail/rxtx/2009-November/5778408.html I have disocvered one technique which solved this problem in Linux Ubuntu and Mac for RXTX pre2.2, but should helps in 2.1.7 as well. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Thu Feb 25 02:41:46 2010 From: george.dma at gmail.com (George H) Date: Thu, 25 Feb 2010 11:41:46 +0200 Subject: [Rxtx] Lingering rxtx process In-Reply-To: <73a89f361002230029w4a9ec14bt56d654e43c1c9623@mail.gmail.com> References: <73a89f361002230029w4a9ec14bt56d654e43c1c9623@mail.gmail.com> Message-ID: With Mariusz Dec help and with the help of the threads that were mentioned http://mailman.qbang.org/pipermail/rxtx/2009-November/5790326.html http://embeddedfreak.wordpress.com/2008/10/08/rxtx-serial-port-helper/ I managed to solved my problem. I didn't really like it so much. I am not using the InputStream.read(byte[], int, int) method as for me I can break out of reading the stream if I get a '\n' or a 0x00. Either way the below code sample works for me. int data = 0; int len = 0; while(true) { data = commReader.getInputStream().read(); if(data == -1 || data == 0x00 || data == '\n' || commReader.getInputStream().available() < 1) { break; } if(len == buffer.length) { processData(buffer); clearBuffer(); } buffer[len++] = (byte)data; } Before I would loop the while until data != -1. But that blocks on .close() and my program never gets to exit. Adding .available() < 1 as a break condition fixes it when I call .close() I am going to see if this is a linux kernel configuration issue or not cos it isn't so obvious and I hardly ever use .available() when reading streams. Love the project though :) -- George H george.dma at gmail.com On Tue, Feb 23, 2010 at 10:29 AM, Mariusz Dec wrote: > > > 2010/2/22 George H > > Hi, >> >> I am using RXTX v2.1-7. >> I use it to communicate with 2 serial receipt printers and 1 serial line >> display device. My program runs well using the RXTX library on Windows and >> Linux. >> But... when I installed Linux on another hardware the program does not >> exit properly. By this I mean that the java program seems to have exited >> (passed the System.exit(0)) code but the console still does not return to >> the bash shell. >> >> Thread in Noember 2009' - > > http://mailman.qbang.org/pipermail/rxtx/2009-November/5778408.html > > I have disocvered one technique which solved this problem in Linux Ubuntu > and Mac for RXTX pre2.2, but should helps in 2.1.7 as well. > > Regards > Mariusz > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 01:02:21 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 13:32:21 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> My serial port driver(apparently) does not support receive timeout.I registered an event listener for DATA_AVAILABLE. However, the control never seems to come out of the 'while' loop.Shouldn't the InputStream.read return a '-1' immediately if no data is available (this seems to be the default operation)? This was tried on a x86 Linux desktop using rxtx-2.1-7 I've added the snippet for clarity: /******************************************************************************************************************************************************************************/ mySerialPort.enableReceiveThreshold(2000);//Trying to set a time limit for read calls System.out.println(mySerialPort.isReceiveTimeoutEnabled()); // I get FALSE, so its not supported on hardware. mySerialPort.addEventListener(this); mySerialPort.notifyOnDataAvailable(true);//register a event with //my SerialEvent listener implementation: public void serialEvent(SerialPortEvent arg0) { int newData=0; switch(arg0.getEventType()){ case SerialPortEvent.DATA_AVAILABLE: while (newData != -1) { try { newData = is.read();//This should eventually return a -1 if no data is available within a timeout.PROBLEM!! System.out.println("Got a byte from port:"+newData); if (newData == -1) { break; } } catch (IOException ex) { System.err.println(ex); return; } } break; } return; } /******************************************************************************************************************************************************************************/ Thanks and regards, Ravi From michael.erskine at ketech.com Wed Feb 3 02:26:50 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 09:26:50 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From michael.erskine at ketech.com Wed Feb 3 05:03:30 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 12:03:30 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > Michael Erskine > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > > Your event handler should handle the event and return immediately so that its > controlling thread can handle other events. I recommend a single read in the > following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) > reads all available bytes up to the size of the buffer returning the number of > bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } After posting this I considered the glaring possibility of the rawbuf read buffer being too small to receive all the available bytes and perhaps skipping data: after all, I'm guessing that is why we see so many posts asking for help with blocking implementations of read event handlers looping on "while(bytes are available)". I've spent this morning writing an extensive multi-threaded unit test suite that includes tests with a tiny buffer compared to the amount of data available and found that no data was being skipped. I now want to know why! The SerialPortEvent.DATA_AVAILABLE event must be being fired again if there is more data available on the input stream. If that is the case then it should be heavily documented with good examples in the wiki to avoid the types of developer anguish we see so regularly. BTW: I'm not at liberty to post the JUnit tests as they use my company's unit test suite framework. Regards, Michael Erskine. From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 06:18:04 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 18:48:04 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Hello Michael, I tried out your suggestion but the problem is that the read(rawbuf) blocks until the entire length of the rawbuf array has been read (blocking). I cannot decide on a reasonable size of the array because it varies from 2 bytes to as much as 50 byes (i'm communicating with a modem,each response is of a different length), which is why i wanted to use non blocking calls. But on a side note, read(byte[]) in turn calls the read() in a loop.In the native C function, the read is supposed to return a -1 upon timeout.But my driver does not support timeout.The default timeout value is zero and the linux select call upon zero time out causes an infinite wait.What am i missing...... Thanks and regards, Ravi Date: Wed, 3 Feb 2010 09:26:50 +0000 From: Michael Erskine To: "rxtx at qbang.org" Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: Content-Type: text/plain; charset="us-ascii" > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From m.kirkland at comcast.net Wed Feb 3 06:46:03 2010 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 3 Feb 2010 05:46:03 -0800 Subject: [Rxtx] One port blocking another port In-Reply-To: References: Message-ID: <68768633814F4D7D86761D34F0764FE0@bengal.net> It turns out this is caused by having the RTS/CTS flow control turned on and me not providing a true on the RTS pin. Somehow it seems the port timing out on a read allows the write to proceed. This is not an issue for my application but I wonder if the write should not proceed until the RTS pin is true even if a read times out. mk -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Monday, January 25, 2010 7:48 PM To: Mike Kirkland Cc: rxtx at qbang.org Subject: Re: [Rxtx] One port blocking another port On Mon, 25 Jan 2010, Mike Kirkland wrote: > > Hi All, > > ? > > I have a program that reads from one com port and writes to another com > port. It also does the same thing in reverse (reads from the second com port > and writes to the first one. It basically ties two com ports together. > > ? > > One port is very chatty and has a consent stream of data. The other port has > very little data. > > ? > > Both ports use a 5000 ms (5 second) time out. > > ? > > The issue I am having is that is appears that the first port?s write to the > second port is blocked while the second port is waiting for input. The first > port?s write proceeds only after the second port has timed out. > > ? > > I suppose I could have something twisted around in my code but I was > wondering if this is a know issue? > Hi Kirk, I've not seen a report like this. Perhaps some simple reproduction code will reveal a problem on your end or help us identify a problem in rxtx. I think there are several users doing multiport communication. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Wed Feb 3 07:03:58 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:03:58 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Message-ID: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> 2010/2/3 Ravishankar N > Hello Michael, > [..] > But on a side note, read(byte[]) in turn calls the read() in a loop.In the > native C function, the read is supposed to return a -1 upon timeout.But my > driver > does not support timeout.The default timeout value is zero and the linux > select call upon zero time out causes an infinite wait.What am i > missing...... > > When I have tested RXTX between platforms, I have observed "hangup" inside JNI driver when no data in Linux, is normal thing. Solution was setting the timeout for RXTX when no data from JNI driver. Something like that: commPort.enableReceiveTimeout(10); And it works perfect.... The only difference is that I am NOT using events - I am using continous read in separate thread and if data is available, is parsed and transferred to application using exception. Regards Mariusz > Thanks and regards, > Ravi > > Date: Wed, 3 Feb 2010 09:26:50 +0000 > From: Michael Erskine > To: "rxtx at qbang.org" > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > Message-ID: > > > Content-Type: text/plain; charset="us-ascii" > > > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of > > Ravishankar N > > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > > > My serial port driver(apparently) does not support receive timeout.I > > registered an event listener for DATA_AVAILABLE. However, the control > never > > seems to come out of the 'while' loop.Shouldn't the > > InputStream.read return a '-1' immediately if no data is available (this > seems > > to be the default operation)? > > Your event handler should handle the event and return immediately so that > its controlling thread can handle other events. I recommend a single read in > the following manner: rawbuf is a byte[] of "reasonable" size and the > read(byte[]) reads all available bytes up to the size of the buffer > returning the number of bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } > > This style of reading has worked for me with RXTX on Linux and Windows XP > for a good few years now in railway industry communications systems. Any > timeouts (largely unnecessary in my applications) can be handled elsewhere, > usually at a higher layer. > > Regards, > Michael Erskine. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Feb 3 07:22:55 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 3 Feb 2010 09:22:55 -0500 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: I'm guessing that this is driver specific. I recently had to support a select()/poll() infrastructure for a linux serial DD, its certainly non trivial to support async IO, so I suspect the problem in this case has to do with missing poll infrastructure in the device driver. This also has to coupled with special open flags for the device (which is within the rxtx code) The key routines within a 2.6 kernel linux device driver are shown below (if you have access to it for your particular device) are indicated below (here is a snippet from my device driver c code that supports polling/select). User space code to test this shown below also, note that the device needs to be opened with the O_NONBLOCK option to support the select/poll api // device driver code ..... /* * File operations supported by this driver. */ static struct file_operations iop_fops = { .owner = THIS_MODULE, .check_flags= iop_check_flags, .ioctl = iop_ioctl, .open = iop_open, .poll = iop_poll, // SUPPORT FOR SELECT/POLL infrastructure .read = iop_read, .release = iop_release, .write = iop_write, }; /** * Select/poll/epoll infrastructure. * * @param file * @param wait * * @return */ static unsigned int iop_poll(struct file *filp, poll_table *wait) { struct iop_device *devp = (struct iop_device *)filp->private_data; // the poll_table wait arg is an opaque pointer poll_wait(filp, &devp->readq, wait); // return from poll indicating whether we have read/write data unsigned int mask = 0; if (kfifo_len(devp->rx_fifo)) { mask |= (POLLIN | POLLRDNORM); } // @JC We don't do select on write yet // if (kfifo_len(devp->tx_fifo)) { // mask |= (POLLOUT | POLLWRNORM); // } // Only print out while debugging // if (mask != 0) { // printk (KERN_INFO "%s: [%04x]\n", __FUNCTION__, mask); // } return mask; } /** * device driver blocking and non blocking read function. This * function reads the requested number of bytes from the read * kfifo blocking as required. * * @param filp * @param buf * @param count * @param f_pos * * @return */ static ssize_t iop_read(struct file *filp, char __user *buf, size_t count, loff_t * ppos) { // access appropriate device struct struct iop_device *devp = (struct iop_device *) filp->private_data; ssize_t retval; // support non blocking mode (default) by checking if the kfifo is empty first if ((kfifo_len(devp->rx_fifo)==0) && (filp->f_flags & O_NONBLOCK)) { return -EAGAIN; } // wait for rx_fifo to receive data via receive interrupts retval = wait_event_interruptible(devp->readq, kfifo_len(devp->rx_fifo) != 0); // check for some error condition if (retval) { printk (KERN_ERR "%s: wait_event_interruptible returned[%d]\n", __FUNCTION__, retval); return retval; } // copy max requested bytes from rx_fifo to device buffer // this may still leave bytes in the kfifo for a subsequent read // if we are reading in a loop retval = kfifo_get(devp->rx_fifo, devp->rxbuf, count); // printk (KERN_INFO "%s: [%d] byte(s)\n", __FUNCTION__, retval); if (copy_to_user(buf, devp->rxbuf, retval)) { printk (KERN_ERR "%s: problem copying rx_fifo data to user buffer\n", __FUNCTION__); return -EFAULT; } return retval; } // a selection of my user space code reading via select()/poll()..... // user space open code iop_fd = ::open( deviceName.data(), O_RDWR | O_NONBLOCK); while ((bytes_to_expect - bytes_read) > 0) { // must reinitialize these between select calls fd_set readfds; FD_ZERO( &readfds ); FD_SET( iop_fd, &readfds ); // 1s sec read polling timeout struct timeval timeout; timeout.tv_sec = 1; timeout.tv_usec = 0; int rc = select( FD_SETSIZE, &readfds, NULL, NULL, &timeout ); // read from file when descriptor // indicates data available without blocking if ((rc > 0) && FD_ISSET(iop_fd, &readfds)) { // read into the appropriate offset within the rx_buf int temp = read(iop_fd, rx_buf + bytes_read, bytes_to_expect - bytes_read); if (!temp) { printf("EOF detected with %d bytes expected\n", bytes_to_expect - bytes_read); } else { bytes_read += temp; } } else if (rc < 0){ printf("%s: select on [%s], bytes_read[%d], errno=%d\n", __FUNCTION__, thread_args->device, bytes_read, errno); } else { printf("%s: select on [%s], bytes_read[%d], timeout\n", __FUNCTION__, thread_args->device, bytes_read); } } On Wed, Feb 3, 2010 at 9:03 AM, Mariusz Dec wrote: > > > 2010/2/3 Ravishankar N > >> Hello Michael, >> [..] >> >> But on a side note, read(byte[]) in turn calls the read() in a loop.In the >> native C function, the read is supposed to return a -1 upon timeout.But my >> driver >> does not support timeout.The default timeout value is zero and the linux >> select call upon zero time out causes an infinite wait.What am i >> missing...... >> >> > When I have tested RXTX between platforms, I have observed "hangup" inside > JNI driver when no data in Linux, is normal thing. > > Solution was setting the timeout for RXTX when no data from JNI driver. > > Something like that: > > commPort.enableReceiveTimeout(10); > > And it works perfect.... > > The only difference is that I am NOT using events - I am using continous > read in separate thread and if data is available, is parsed and transferred > to application using exception. > > Regards > Mariusz > > > >> Thanks and regards, >> Ravi >> >> Date: Wed, 3 Feb 2010 09:26:50 +0000 >> From: Michael Erskine >> To: "rxtx at qbang.org" >> Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? >> Message-ID: >> >> >> Content-Type: text/plain; charset="us-ascii" >> >> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >> Of >> > Ravishankar N >> > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? >> > >> > My serial port driver(apparently) does not support receive timeout.I >> > registered an event listener for DATA_AVAILABLE. However, the control >> never >> > seems to come out of the 'while' loop.Shouldn't the >> > InputStream.read return a '-1' immediately if no data is available (this >> seems >> > to be the default operation)? >> >> Your event handler should handle the event and return immediately so that >> its controlling thread can handle other events. I recommend a single read in >> the following manner: rawbuf is a byte[] of "reasonable" size and the >> read(byte[]) reads all available bytes up to the size of the buffer >> returning the number of bytes actually read... >> >> case SerialPortEvent.DATA_AVAILABLE: >> try { >> int i = is.read(rawbuf); >> if (i == -1) { >> << process EOF condition - should never happen >> >> return; >> } >> << process bytes (rawbuf, i); >> >> return; >> } catch (IOException e) { >> << promptly deal with exception >> >> return; >> } >> >> This style of reading has worked for me with RXTX on Linux and Windows XP >> for a good few years now in railway industry communications systems. Any >> timeouts (largely unnecessary in my applications) can be handled elsewhere, >> usually at a higher layer. >> >> Regards, >> Michael Erskine. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Feb 3 07:33:27 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:33:27 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: <73a89f361002030633j682610afia48dc7accd8e049b@mail.gmail.com> 2010/2/3 John Coffey > I'm guessing that this is driver specific. I recently had to support a > select()/poll() infrastructure for a linux serial DD, its certainly non > trivial to support async IO, so I suspect the problem in this case has to do > with missing poll infrastructure in the device driver. This also has to > coupled with special open flags for the device (which is within the rxtx > code) > > Yes, you are right, it may be driver specific, but in my case I haven't changed blocking JNI driver. I have added ONLY one call to RXTX method mentioned in my previous post and blocking (as seen as from Java app) gone out... Maybe this is not elegant, but works without problem in my app. I am using only FTDI chips and their drivers from couple of years and maybe this is the kind of the way to have no many problems with serial as well? Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From andyrxtx at g0poy.co.uk Wed Feb 3 11:09:04 2010 From: andyrxtx at g0poy.co.uk (andyrxtx at g0poy.co.uk) Date: Wed, 3 Feb 2010 18:09:04 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes Message-ID: <20100203180904.164f24dd@workstation.site> ?Hello RXTX group, I have just joined this group, and this is my first posting. I wanted to pass on some information regarding rxtx, so apologies if this has been brought up before. I have searched back through the archives but nothing specific came up. I am not a Java programmer, and I only came across rxtx a few days ago. I use a piece of test equipment called a miniVNA http://www.miniradiosolutions.com/ This is a serial USB controlled instrument, and it has control software available for MS windows, and a very old and now non-working Linux application. A few days ago Dietmar, DL2SBA released a Java application to control the miniVNA, obviously this application makes use of rxtx. The program worked fine on Windows, so I set about installing it onto Linux. I use SUSE11.1 After a few false starts, I got the system running fairly easily, sorting out the file locking by adding the uucp group to the users account as suggested (I used the 2.2pre binary files) I then passed the install instructions onto another miniVNA user, who also uses SUSE, but he ran into problems. To cut a long story short, he was also having file lock problems, but the uucp fix did not work. Digging into his system I found that there have been some changes in SUSE 11.2. tty ports are now assigned to the dialout group rather than uucp. A hint in the rxtx INSTALL file, suggested that var/lock needs to be checked, so: SUSE 11.1, var/lock is root:uucp SUSE 11.2 var/lock is root:root A search on Google brought up several comments regarding this, and also a bugzilla entry. https://bugzilla.novell.com/show_bug.cgi?id=552095 However from reading the various posts, some of which are in the bugzilla entry, it appears that many distros may be, or have changed to this configuration, and this will undoubtedly break several things, rxtx included. I solved my fellow SUSE users problem by compiling the rxtx libs with the no lock file option during configure, and that solved his problem. As this issue will probably take some time to get resolved across all the various Linux distros, it might be worth considering changing the default on the Linux build of rxtx not to use lockfiles, or provide the two versions of the lib in the binary archive. Thanks for your indulgence Andy From damorales at gmail.com Wed Feb 3 11:33:23 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 15:33:23 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203180904.164f24dd@workstation.site> References: <20100203180904.164f24dd@workstation.site> Message-ID: Hi I had the same problem in Mandriva 2010 and yes, adding the user to the uucp group did not work as it used to be in earlier versions of linux distros, causing RXTX to not work as non root user. The problem appears because the existense of UDEV, now you MUST add a RULE so the group (uucp or whatever) have access (Read, Write, Execute) to the Serial Port. To solve the problem, without needing to recompile RXTX, you must add a rule to grant permissions (0666) to the group for the device or port (tty*, ttyUSB*, etc). I do not remember now what is the line i added but when i come back home i will give it to you (i am at work now). Greetings ! 2010/2/3 > Hello RXTX group, > > I have just joined this group, and this is my first posting. > I wanted to pass on some information regarding rxtx, so apologies if > this has been brought up before. I have searched back through the > archives but nothing specific came up. > > I am not a Java programmer, and I only came across rxtx a few days ago. > > I use a piece of test equipment called a miniVNA > http://www.miniradiosolutions.com/ > > This is a serial USB controlled instrument, and it has control software > available for MS windows, and a very old and now non-working Linux > application. > > A few days ago Dietmar, DL2SBA released a Java application to control the > miniVNA, obviously this application makes use of rxtx. > > The program worked fine on Windows, so I set about installing it onto > Linux. I use SUSE11.1 After a few false starts, I got the system running > fairly easily, sorting out the file locking by adding the uucp group to > the users account as suggested (I used the 2.2pre binary files) I then > passed the install instructions onto another miniVNA user, who also uses > SUSE, but he ran into problems. To cut a long story short, he was > also having file lock problems, but the uucp fix did not work. Digging > into his system I found that there have been some changes in SUSE 11.2. > > tty ports are now assigned to the dialout group rather than uucp. > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > checked, so: > > SUSE 11.1, var/lock is root:uucp > SUSE 11.2 var/lock is root:root > > A search on Google brought up several comments regarding this, and also > a bugzilla entry. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > However from reading the various posts, some of which are in the bugzilla > entry, it appears that many distros may be, or have changed to this > configuration, and this will undoubtedly break several things, rxtx > included. > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > no lock file option during configure, and that solved his problem. > > As this issue will probably take some time to get resolved across all the > various Linux distros, it might be worth considering changing the default > on the Linux build of rxtx not to use lockfiles, or provide the two > versions of the lib in the binary archive. > > Thanks for your indulgence > > Andy > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Wed Feb 3 12:07:02 2010 From: andy at g0poy.com (Andy Eskelson) Date: Wed, 3 Feb 2010 19:07:02 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> Message-ID: <20100203190702.1b0e7015@workstation.site> Thanks Daniel, I am aware of the permissions problem, I have had a udev rules to solve this for other programs for some time. . I don't think that this is the same problem. as far as I can understand things, the lock files are written in var/lock. Previously var/lock and dev/tty-whatever were the same group. Now with var/lock owned by and with a group of root:root anything other than root cannot create a lock file. Even minicom is broken by this change. This change is going to have quite a few knock-on effects I think. Andy On Wed, 3 Feb 2010 15:33:23 -0300 Daniel Morales Salas wrote: > Hi > > I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > group did not work as it used to be in earlier versions of linux distros, > causing RXTX to not work as non root user. > > The problem appears because the existense of UDEV, now you MUST add a RULE > so the group (uucp or whatever) have access (Read, Write, Execute) to the > Serial Port. > > To solve the problem, without needing to recompile RXTX, you must add a rule > to grant permissions (0666) to the group for the device or port (tty*, > ttyUSB*, etc). I do not remember now what is the line i added but when i > come back home i will give it to you (i am at work now). > > Greetings ! > > 2010/2/3 > > > Hello RXTX group, > > > > I have just joined this group, and this is my first posting. > > I wanted to pass on some information regarding rxtx, so apologies if > > this has been brought up before. I have searched back through the > > archives but nothing specific came up. > > > > I am not a Java programmer, and I only came across rxtx a few days ago. > > > > I use a piece of test equipment called a miniVNA > > http://www.miniradiosolutions.com/ > > > > This is a serial USB controlled instrument, and it has control software > > available for MS windows, and a very old and now non-working Linux > > application. > > > > A few days ago Dietmar, DL2SBA released a Java application to control the > > miniVNA, obviously this application makes use of rxtx. > > > > The program worked fine on Windows, so I set about installing it onto > > Linux. I use SUSE11.1 After a few false starts, I got the system running > > fairly easily, sorting out the file locking by adding the uucp group to > > the users account as suggested (I used the 2.2pre binary files) I then > > passed the install instructions onto another miniVNA user, who also uses > > SUSE, but he ran into problems. To cut a long story short, he was > > also having file lock problems, but the uucp fix did not work. Digging > > into his system I found that there have been some changes in SUSE 11.2. > > > > tty ports are now assigned to the dialout group rather than uucp. > > > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > checked, so: > > > > SUSE 11.1, var/lock is root:uucp > > SUSE 11.2 var/lock is root:root > > > > A search on Google brought up several comments regarding this, and also > > a bugzilla entry. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > However from reading the various posts, some of which are in the bugzilla > > entry, it appears that many distros may be, or have changed to this > > configuration, and this will undoubtedly break several things, rxtx > > included. > > > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > > no lock file option during configure, and that solved his problem. > > > > As this issue will probably take some time to get resolved across all the > > various Linux distros, it might be worth considering changing the default > > on the Linux build of rxtx not to use lockfiles, or provide the two > > versions of the lib in the binary archive. > > > > Thanks for your indulgence > > > > Andy > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From thisdyingdream at gmail.com Wed Feb 3 12:32:35 2010 From: thisdyingdream at gmail.com (Steven Harms) Date: Wed, 3 Feb 2010 14:32:35 -0500 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203190702.1b0e7015@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: This is currently a bug in OpenSUSE that affects more than just rxtx, and is a result of unified udev rules. You can work around this by making udev change the group back to uucp until something more happens. https://bugzilla.novell.com/show_bug.cgi?id=552095 Thanks, Steve On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > Thanks Daniel, > > I am aware of the permissions problem, I have had a udev rules to solve > this for other programs for some time. > . > I don't think that this is the same problem. as far as I can understand > things, the lock files are written in var/lock. Previously var/lock and > dev/tty-whatever were the same group. Now with var/lock owned by and with > a group of root:root anything other than root cannot create a lock > file. Even minicom is broken by this change. > > This change is going to have quite a few knock-on effects I think. > > > Andy > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > Daniel Morales Salas wrote: > >> Hi >> >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp >> group did not work as it used to be in earlier versions of linux distros, >> causing RXTX to not work as non root user. >> >> The problem appears because the existense of UDEV, now you MUST add a RULE >> so the group (uucp or whatever) have access (Read, Write, Execute) to the >> Serial Port. >> >> To solve the problem, without needing to recompile RXTX, you must add a rule >> to grant permissions (0666) to the group for the device or port (tty*, >> ttyUSB*, etc). I do not remember now what is the line i added but when i >> come back home i will give it to you (i am at work now). >> >> Greetings ! >> >> 2010/2/3 >> >> > Hello RXTX group, >> > >> > I have just joined this group, and this is my first posting. >> > I wanted to pass on ?some information regarding rxtx, so apologies if >> > this has been brought up before. I have searched back through the >> > archives but nothing specific came up. >> > >> > I am not a Java programmer, and I only came across rxtx a few days ago. >> > >> > I use a piece of test equipment called a miniVNA >> > http://www.miniradiosolutions.com/ >> > >> > This is a serial USB controlled instrument, and it has control software >> > available for MS windows, and a very old and now non-working Linux >> > application. >> > >> > A few days ago Dietmar, DL2SBA released a Java application to control the >> > miniVNA, obviously this application makes use of rxtx. >> > >> > The program worked fine on Windows, so I set about installing it onto >> > Linux. I use SUSE11.1 After a few false starts, I got the system running >> > fairly easily, sorting out the file locking by adding the uucp group to >> > the users account as suggested (I used the 2.2pre binary files) I then >> > passed the install instructions onto another miniVNA user, who also uses >> > SUSE, but he ran into problems. To cut a long story short, he was >> > also having file lock problems, but the uucp fix did not work. Digging >> > into his system I found that there have been some changes in SUSE 11.2. >> > >> > tty ports are now assigned to the dialout group rather than uucp. >> > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be >> > checked, so: >> > >> > SUSE 11.1, var/lock is root:uucp >> > SUSE 11.2 var/lock is root:root >> > >> > A search on Google brought up several comments regarding this, and also >> > a ?bugzilla entry. >> > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 >> > >> > However from reading the various posts, some of which are in the bugzilla >> > entry, it appears that many distros may be, or have changed to this >> > configuration, and this will undoubtedly break several things, rxtx >> > included. >> > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the >> > no lock file option during configure, and that solved his problem. >> > >> > As this issue will probably take some time to get resolved across all the >> > various Linux distros, it might be worth considering changing the default >> > on the Linux build of rxtx not to use lockfiles, or provide the two >> > versions of the lib in the binary archive. >> > >> > Thanks for your indulgence >> > >> > Andy >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> >> >> >> -- >> Atte: >> Daniel Dario Morales Salas >> Ingeniero Civil en Computaci?n e Inform?tica >> Tel?fono: 02 684 3417 >> Celular: 09 643 1802 >> Santiago, Chile > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 WWW: http://www.sharms.org/blog From andy at g0poy.com Wed Feb 3 17:58:29 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 00:58:29 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: <20100204005829.7dc944e1@workstation.site> Thanks Steve, changing the serial ports back the uucp is not a big problem. I have a udev rule that can be easily modified already. However I cannot see any way of dealing with the var/lock problem apart from making it writable to all. Any thoughts? Andy On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms wrote: > This is currently a bug in OpenSUSE that affects more than just rxtx, > and is a result of unified udev rules. You can work around this by > making udev change the group back to uucp until something more > happens. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > Thanks, > > Steve > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > Thanks Daniel, > > > > I am aware of the permissions problem, I have had a udev rules to solve > > this for other programs for some time. > > . > > I don't think that this is the same problem. as far as I can understand > > things, the lock files are written in var/lock. Previously var/lock and > > dev/tty-whatever were the same group. Now with var/lock owned by and with > > a group of root:root anything other than root cannot create a lock > > file. Even minicom is broken by this change. > > > > This change is going to have quite a few knock-on effects I think. > > > > > > Andy > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > Daniel Morales Salas wrote: > > > >> Hi > >> > >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > >> group did not work as it used to be in earlier versions of linux distros, > >> causing RXTX to not work as non root user. > >> > >> The problem appears because the existense of UDEV, now you MUST add a RULE > >> so the group (uucp or whatever) have access (Read, Write, Execute) to the > >> Serial Port. > >> > >> To solve the problem, without needing to recompile RXTX, you must add a rule > >> to grant permissions (0666) to the group for the device or port (tty*, > >> ttyUSB*, etc). I do not remember now what is the line i added but when i > >> come back home i will give it to you (i am at work now). > >> > >> Greetings ! > >> > >> 2010/2/3 > >> > >> > Hello RXTX group, > >> > > >> > I have just joined this group, and this is my first posting. > >> > I wanted to pass on ?some information regarding rxtx, so apologies if > >> > this has been brought up before. I have searched back through the > >> > archives but nothing specific came up. > >> > > >> > I am not a Java programmer, and I only came across rxtx a few days ago. > >> > > >> > I use a piece of test equipment called a miniVNA > >> > http://www.miniradiosolutions.com/ > >> > > >> > This is a serial USB controlled instrument, and it has control software > >> > available for MS windows, and a very old and now non-working Linux > >> > application. > >> > > >> > A few days ago Dietmar, DL2SBA released a Java application to control the > >> > miniVNA, obviously this application makes use of rxtx. > >> > > >> > The program worked fine on Windows, so I set about installing it onto > >> > Linux. I use SUSE11.1 After a few false starts, I got the system running > >> > fairly easily, sorting out the file locking by adding the uucp group to > >> > the users account as suggested (I used the 2.2pre binary files) I then > >> > passed the install instructions onto another miniVNA user, who also uses > >> > SUSE, but he ran into problems. To cut a long story short, he was > >> > also having file lock problems, but the uucp fix did not work. Digging > >> > into his system I found that there have been some changes in SUSE 11.2. > >> > > >> > tty ports are now assigned to the dialout group rather than uucp. > >> > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > >> > checked, so: > >> > > >> > SUSE 11.1, var/lock is root:uucp > >> > SUSE 11.2 var/lock is root:root > >> > > >> > A search on Google brought up several comments regarding this, and also > >> > a ?bugzilla entry. > >> > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > >> > > >> > However from reading the various posts, some of which are in the bugzilla > >> > entry, it appears that many distros may be, or have changed to this > >> > configuration, and this will undoubtedly break several things, rxtx > >> > included. > >> > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the > >> > no lock file option during configure, and that solved his problem. > >> > > >> > As this issue will probably take some time to get resolved across all the > >> > various Linux distros, it might be worth considering changing the default > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > >> > versions of the lib in the binary archive. > >> > > >> > Thanks for your indulgence > >> > > >> > Andy > >> > > >> > _______________________________________________ > >> > Rxtx mailing list > >> > Rxtx at qbang.org > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > >> > >> > >> > >> -- > >> Atte: > >> Daniel Dario Morales Salas > >> Ingeniero Civil en Computaci?n e Inform?tica > >> Tel?fono: 02 684 3417 > >> Celular: 09 643 1802 > >> Santiago, Chile > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > WWW: http://www.sharms.org/blog From damorales at gmail.com Wed Feb 3 18:26:38 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 22:26:38 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100204005829.7dc944e1@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: Hello I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva 2010 this is what i get: drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ and i don't have ANY problem with lock files and RXTX in my java software. All i had to do was add this rule to udev: # serial KERNEL=="tty*", GROUP="uucp", MODE="0666" and that was all. Of course my user (metalklesk) is part of uucp group. I did not make /var/lock writable to all users. Greetings ! 2010/2/3 Andy Eskelson > Thanks Steve, > > changing the serial ports back the uucp is not a big problem. I have a > udev rule that can be easily modified already. However I cannot see any > way of dealing with the var/lock problem apart from making it writable to > all. Any thoughts? > > Andy > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > wrote: > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > and is a result of unified udev rules. You can work around this by > > making udev change the group back to uucp until something more > > happens. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > Thanks, > > > > Steve > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > Thanks Daniel, > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > this for other programs for some time. > > > . > > > I don't think that this is the same problem. as far as I can understand > > > things, the lock files are written in var/lock. Previously var/lock and > > > dev/tty-whatever were the same group. Now with var/lock owned by and > with > > > a group of root:root anything other than root cannot create a lock > > > file. Even minicom is broken by this change. > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > Daniel Morales Salas wrote: > > > > > >> Hi > > >> > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > the uucp > > >> group did not work as it used to be in earlier versions of linux > distros, > > >> causing RXTX to not work as non root user. > > >> > > >> The problem appears because the existense of UDEV, now you MUST add a > RULE > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > the > > >> Serial Port. > > >> > > >> To solve the problem, without needing to recompile RXTX, you must add > a rule > > >> to grant permissions (0666) to the group for the device or port (tty*, > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > i > > >> come back home i will give it to you (i am at work now). > > >> > > >> Greetings ! > > >> > > >> 2010/2/3 > > >> > > >> > Hello RXTX group, > > >> > > > >> > I have just joined this group, and this is my first posting. > > >> > I wanted to pass on some information regarding rxtx, so apologies > if > > >> > this has been brought up before. I have searched back through the > > >> > archives but nothing specific came up. > > >> > > > >> > I am not a Java programmer, and I only came across rxtx a few days > ago. > > >> > > > >> > I use a piece of test equipment called a miniVNA > > >> > http://www.miniradiosolutions.com/ > > >> > > > >> > This is a serial USB controlled instrument, and it has control > software > > >> > available for MS windows, and a very old and now non-working Linux > > >> > application. > > >> > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > control the > > >> > miniVNA, obviously this application makes use of rxtx. > > >> > > > >> > The program worked fine on Windows, so I set about installing it > onto > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > running > > >> > fairly easily, sorting out the file locking by adding the uucp group > to > > >> > the users account as suggested (I used the 2.2pre binary files) I > then > > >> > passed the install instructions onto another miniVNA user, who also > uses > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > >> > also having file lock problems, but the uucp fix did not work. > Digging > > >> > into his system I found that there have been some changes in SUSE > 11.2. > > >> > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > >> > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > >> > checked, so: > > >> > > > >> > SUSE 11.1, var/lock is root:uucp > > >> > SUSE 11.2 var/lock is root:root > > >> > > > >> > A search on Google brought up several comments regarding this, and > also > > >> > a bugzilla entry. > > >> > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > >> > > > >> > However from reading the various posts, some of which are in the > bugzilla > > >> > entry, it appears that many distros may be, or have changed to this > > >> > configuration, and this will undoubtedly break several things, rxtx > > >> > included. > > >> > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > with the > > >> > no lock file option during configure, and that solved his problem. > > >> > > > >> > As this issue will probably take some time to get resolved across > all the > > >> > various Linux distros, it might be worth considering changing the > default > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > >> > versions of the lib in the binary archive. > > >> > > > >> > Thanks for your indulgence > > >> > > > >> > Andy > > >> > > > >> > _______________________________________________ > > >> > Rxtx mailing list > > >> > Rxtx at qbang.org > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > >> > > > >> > > >> > > >> > > >> -- > > >> Atte: > > >> Daniel Dario Morales Salas > > >> Ingeniero Civil en Computaci?n e Inform?tica > > >> Tel?fono: 02 684 3417 > > >> Celular: 09 643 1802 > > >> Santiago, Chile > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at qbang.org > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > -- > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > WWW: http://www.sharms.org/blog > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Thu Feb 4 05:31:46 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 12:31:46 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: <20100204123146.6cffeb67@workstation.site> Thank's for the confirmation. Something odd is going on somewhere in SUSE 11.2. I'll have to build up a local SUSE11.2 system to see if I can nail down exactly what is going on. Something is blocking the lockfiles in var/lock. The net is nice, but it's a bit difficult trying to work out what is going on what the machine in question is in Germany and I'm in the UK :-) Andy On Wed, 3 Feb 2010 22:26:38 -0300 Daniel Morales Salas wrote: > Hello > > I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva > 2010 this is what i get: > > drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ > > and i don't have ANY problem with lock files and RXTX in my java software. > All i had to do was add this rule to udev: > > # serial > KERNEL=="tty*", GROUP="uucp", MODE="0666" > > and that was all. Of course my user (metalklesk) is part of uucp group. > I did not make /var/lock writable to all users. > > Greetings ! > > 2010/2/3 Andy Eskelson > > > Thanks Steve, > > > > changing the serial ports back the uucp is not a big problem. I have a > > udev rule that can be easily modified already. However I cannot see any > > way of dealing with the var/lock problem apart from making it writable to > > all. Any thoughts? > > > > Andy > > > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > > wrote: > > > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > > and is a result of unified udev rules. You can work around this by > > > making udev change the group back to uucp until something more > > > happens. > > > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > > > Thanks, > > > > > > Steve > > > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > > Thanks Daniel, > > > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > > this for other programs for some time. > > > > . > > > > I don't think that this is the same problem. as far as I can understand > > > > things, the lock files are written in var/lock. Previously var/lock and > > > > dev/tty-whatever were the same group. Now with var/lock owned by and > > with > > > > a group of root:root anything other than root cannot create a lock > > > > file. Even minicom is broken by this change. > > > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > > Daniel Morales Salas wrote: > > > > > > > >> Hi > > > >> > > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > > the uucp > > > >> group did not work as it used to be in earlier versions of linux > > distros, > > > >> causing RXTX to not work as non root user. > > > >> > > > >> The problem appears because the existense of UDEV, now you MUST add a > > RULE > > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > > the > > > >> Serial Port. > > > >> > > > >> To solve the problem, without needing to recompile RXTX, you must add > > a rule > > > >> to grant permissions (0666) to the group for the device or port (tty*, > > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > > i > > > >> come back home i will give it to you (i am at work now). > > > >> > > > >> Greetings ! > > > >> > > > >> 2010/2/3 > > > >> > > > >> > Hello RXTX group, > > > >> > > > > >> > I have just joined this group, and this is my first posting. > > > >> > I wanted to pass on some information regarding rxtx, so apologies > > if > > > >> > this has been brought up before. I have searched back through the > > > >> > archives but nothing specific came up. > > > >> > > > > >> > I am not a Java programmer, and I only came across rxtx a few days > > ago. > > > >> > > > > >> > I use a piece of test equipment called a miniVNA > > > >> > http://www.miniradiosolutions.com/ > > > >> > > > > >> > This is a serial USB controlled instrument, and it has control > > software > > > >> > available for MS windows, and a very old and now non-working Linux > > > >> > application. > > > >> > > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > > control the > > > >> > miniVNA, obviously this application makes use of rxtx. > > > >> > > > > >> > The program worked fine on Windows, so I set about installing it > > onto > > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > > running > > > >> > fairly easily, sorting out the file locking by adding the uucp group > > to > > > >> > the users account as suggested (I used the 2.2pre binary files) I > > then > > > >> > passed the install instructions onto another miniVNA user, who also > > uses > > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > > >> > also having file lock problems, but the uucp fix did not work. > > Digging > > > >> > into his system I found that there have been some changes in SUSE > > 11.2. > > > >> > > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > > >> > > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > > >> > checked, so: > > > >> > > > > >> > SUSE 11.1, var/lock is root:uucp > > > >> > SUSE 11.2 var/lock is root:root > > > >> > > > > >> > A search on Google brought up several comments regarding this, and > > also > > > >> > a bugzilla entry. > > > >> > > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > >> > > > > >> > However from reading the various posts, some of which are in the > > bugzilla > > > >> > entry, it appears that many distros may be, or have changed to this > > > >> > configuration, and this will undoubtedly break several things, rxtx > > > >> > included. > > > >> > > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > > with the > > > >> > no lock file option during configure, and that solved his problem. > > > >> > > > > >> > As this issue will probably take some time to get resolved across > > all the > > > >> > various Linux distros, it might be worth considering changing the > > default > > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > > >> > versions of the lib in the binary archive. > > > >> > > > > >> > Thanks for your indulgence > > > >> > > > > >> > Andy > > > >> > > > > >> > _______________________________________________ > > > >> > Rxtx mailing list > > > >> > Rxtx at qbang.org > > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > > >> > > > > >> > > > >> > > > >> > > > >> -- > > > >> Atte: > > > >> Daniel Dario Morales Salas > > > >> Ingeniero Civil en Computaci?n e Inform?tica > > > >> Tel?fono: 02 684 3417 > > > >> Celular: 09 643 1802 > > > >> Santiago, Chile > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at qbang.org > > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > > > -- > > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > > > WWW: http://www.sharms.org/blog > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From Bob_Jacobsen at lbl.gov Thu Feb 4 09:26:49 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Thu, 4 Feb 2010 08:26:49 -0800 Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 Message-ID: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're using RXTX-2.2pre2, although it emits the known message about "Version mismatch". WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 After the usual messing around, we've got it working on 11 Windows versions, multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ have things working rarely say so, so I don't know whether anybody has gotten it to work on 10.4 or not. The problem encountered is this: dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib dyld: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib followed by the JVM crashing hard. I've got those dump files if that would help. Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If so, is there a patch I can get and build? Thanks Bob -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From tjarvi at qbang.org Thu Feb 4 14:22:21 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 4 Feb 2010 14:22:21 -0700 (MST) Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 In-Reply-To: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> References: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> Message-ID: On Thu, 4 Feb 2010, Bob Jacobsen wrote: > We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're > using RXTX-2.2pre2, although it emits the known message about "Version > mismatch". > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > > After the usual messing around, we've got it working on 11 Windows versions, > multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with > a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ > have things working rarely say so, so I don't know whether anybody has gotten > it to work on 10.4 or not. > > The problem encountered is this: > > dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > dyld: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > followed by the JVM crashing hard. I've got those dump files if that would > help. > > Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If > so, is there a patch I can get and build? > Hi Bob, I talked to a coworker about the problem you ran into. It appears that it is possible to target 'older' Mac systems through makefile configuration changes. "Configuring a Makefile-Based Project If you have a makefile-based project, you can also take advantage of SDK-based development, by adding the appropriate options to your compile and link commands. Using SDKs in makefile-based projects requires GCC 4.0 or later. To choose an SDK, you use the -isysroot option with the compiler and the -syslibroot option with the linker. Both options require that you specify the full path to the desired SDK directory. To set the Deployment OS version in a makefile, use a makefile variable of the form: ENVP= MACOSX_DEPLOYMENT_TARGET=10.4. To use this variable in your makefile, include it in front of your compile and link commands." http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html Or build on the oldest system you want to support. -- Trent Jarvi tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Thu Feb 4 14:56:19 2010 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Thu, 4 Feb 2010 14:56:19 -0700 Subject: [Rxtx] RXTX on 64 Bit Redhat In-Reply-To: References: <4ec9eab61001281448g3dd84910r867619948a4e0d7a@mail.gmail.com> Message-ID: Trent -- Finally fixed all my build related issues. I ran into another issue. On one of my machines my JDK is returning multiple folders for the "java.ext.dirs" (java.ext.dirs -> /opt/jdk1.6.0_17/jre/lib/ext:/usr/java/packages/lib/ext) system property. As a result my JVM wasn't able to detect the gnu.io.rxtx.properties. I am attaching a patch for RXTXCommDriver.java file to check for multiple locations. Also i have to assign permission 660 to all my dev ports to be located by RXTX. Pawan ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 5:12 PM To: Trent Jarvi Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Here is the error i get when i build the src from release-2-1-7 -bash-3.2$ make ( \ \ cd i686-pc-linux-gnu; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/ jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I/opt/jav a1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec - c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialImp.lo;\ if [ "Serial" = "Serial" ]; then \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I /opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_tim espec -c /home/jb_stg/rxtx/rxtx-devel/./src/fuserImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ else \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo; \ fi; \ ) gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/inclu de -I/opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need _timespec -c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -fPIC -DPIC -o /hom e/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/.libs/SerialImp.o /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:25:29: error: gnu_io_RXTXPort.h: No such file or directory In file included from /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:113: /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:91: error: expected specifier-qua lifier-list before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'jobject' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:408: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:409: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:410: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:411: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:415: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:416: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:417: error: expected '=', ',', '; ', 'asm' or '__attribute__' before 'is_interrupted' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:418: error: expected declaration specifiers or '...' before 'jint' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:424: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:441: error: expected ')' before ' *' token ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 4:57 PM To: Santosh Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Santosh -- Thank you. That fixed the issue. All -- What CVS branch or release should i use to get the latest RXTX src code. Pawan ________________________________ From: Santosh [mailto:santosh.ry at gmail.com] Sent: Thursday, January 28, 2010 3:49 PM To: Kharbanda, Pawan Cc: Trent Jarvi; rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat error "./configure: /bin/sh^M: bad interpreter: No such file or directory". I think you need to run dos2unix on script files before compiling. Thanks, Santosh On Thu, Jan 28, 2010 at 5:33 PM, Kharbanda, Pawan > wrote: Trent -- We are upgrading our exisiting OS and JDK on a project that rely heavily on RXTX api's. We are now using JDK1.6 32 bit (build 1.6.0_17-b04) and RedHat 5 on a 64 bit machine. Linux tocrhstg02.dot.state.co.us 2.6.18-164.6.1.el5 #1 SMP Tue Oct 27 11:30:06 EDT 2009 i686 i686 i386 GNU/Linux Red Hat Enterprise Linux Server release 5.4 (Tikanga) I tried to run version 2.1.7 r2 on it but not able to see any of my Digi ports I was able to access only /dev/ttyS0 (physical ports). Not sure if the problem is with the Digi driver or RXTX. I tried to open a Digi port with minicom and it worked fine. I also tried to get latest from CVS (rxtx-devel) and when I do "configure" I see this error "./configure: /bin/sh^M: bad interpreter: No such file or directory". Can someone please help me with this? Thanks for the help. Pawan _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch.txt URL: From juan.vicente.l.g at gmail.com Sat Feb 13 04:44:17 2010 From: juan.vicente.l.g at gmail.com (Juan Vicente Lopez Gutierrez) Date: Sat, 13 Feb 2010 12:44:17 +0100 Subject: [Rxtx] RXTX in macmini OSX 10.5 Message-ID: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> Hello. My name is Juanvi and I'm from Spain. I tried to launch a software created by me in the library CXR java to send information through the serial port and I can not make it work. In windows if I've done but not mac. I have a mac mini with OSX 10.5 and have read in the list of web mail that you CXR if you have managed to make it work on that operating system. I need you help me please. Do I make the mistake that shows me java: run: Stable Library =============================== Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 gnu.io.PortInUseException: Unknow Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:26) at TwoWatSerialComm.main(TwoWaySerialComm.java:106) Experimental: JNI_OnLoad called. GENERACION CORRECTA (total time: 0 seconds) I do not have permission to access the serial port, do not know. Os agradeceria much to sit down. A greeting and thanks. Pardon my English. Juanvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From juan.vicente.l.g at gmail.com Sat Feb 13 14:39:41 2010 From: juan.vicente.l.g at gmail.com (Juan Vicente Lopez Gutierrez) Date: Sat, 13 Feb 2010 22:39:41 +0100 Subject: [Rxtx] Fwd: RXTX in macmini OSX 10.5 In-Reply-To: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> References: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> Message-ID: <29405e5c1002131339m2059d169sdc8549ed9706a1af@mail.gmail.com> ---------- Forwarded message ---------- From: Juan Vicente Lopez Gutierrez Date: 2010/2/13 Subject: RXTX in macmini OSX 10.5 To: rxtx at qbang.org Hello. My name is Juanvi and I'm from Spain. I tried to launch a software created by me in the library CXR java to send information through the serial port and I can not make it work. In windows if I've done but not mac. I have a mac mini with OSX 10.5 and have read in the list of web mail that you CXR if you have managed to make it work on that operating system. I need you help me please. Do I make the mistake that shows me java: run: Stable Library =============================== Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 gnu.io.PortInUseException: Unknow Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:26) at TwoWatSerialComm.main(TwoWaySerialComm.java:106) Experimental: JNI_OnLoad called. GENERACION CORRECTA (total time: 0 seconds) I do not have permission to access the serial port, do not know. Os agradeceria much to sit down. A greeting and thanks. Pardon my English. Juanvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Mon Feb 22 04:35:48 2010 From: george.dma at gmail.com (George H) Date: Mon, 22 Feb 2010 13:35:48 +0200 Subject: [Rxtx] Lingering rxtx process Message-ID: Hi, I am using RXTX v2.1-7. I use it to communicate with 2 serial receipt printers and 1 serial line display device. My program runs well using the RXTX library on Windows and Linux. But... when I installed Linux on another hardware the program does not exit properly. By this I mean that the java program seems to have exited (passed the System.exit(0)) code but the console still does not return to the bash shell. I have to CTRL+C each time to kill the program. And on each restart RXTX has to remove stale LCK files. Just note I am only getting this on one machine, if it makes any difference it is an i686 system with all VIA chipsets and VIA-C7M NannoBGA2 processor. Any ideas? Thanks -- George H george.dma at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Mon Feb 22 04:43:43 2010 From: george.dma at gmail.com (George H) Date: Mon, 22 Feb 2010 13:43:43 +0200 Subject: [Rxtx] Lingering rxtx process Message-ID: Hi, I am using RXTX v2.1-7. I use it to communicate with 2 serial receipt printers and 1 serial line display device. My program runs well using the RXTX library on Windows and Linux. But... when I installed Linux on another hardware the program does not exit properly. By this I mean that the java program seems to have exited (passed the System.exit(0)) code but the console still does not return to the bash shell. I have to CTRL+C each time to kill the program. And on each restart RXTX has to remove stale LCK files. Just note I am only getting this on one machine, if it makes any difference it is an i686 system with all VIA chipsets and VIA-C7M NannoBGA2 processor. Any ideas? Thanks -- George H george.dma at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Tue Feb 23 01:29:42 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Tue, 23 Feb 2010 09:29:42 +0100 Subject: [Rxtx] Lingering rxtx process In-Reply-To: References: Message-ID: <73a89f361002230029w4a9ec14bt56d654e43c1c9623@mail.gmail.com> 2010/2/22 George H > Hi, > > I am using RXTX v2.1-7. > I use it to communicate with 2 serial receipt printers and 1 serial line > display device. My program runs well using the RXTX library on Windows and > Linux. > But... when I installed Linux on another hardware the program does not exit > properly. By this I mean that the java program seems to have exited (passed > the System.exit(0)) code but the console still does not return to the bash > shell. > > Thread in Noember 2009' - http://mailman.qbang.org/pipermail/rxtx/2009-November/5778408.html I have disocvered one technique which solved this problem in Linux Ubuntu and Mac for RXTX pre2.2, but should helps in 2.1.7 as well. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Thu Feb 25 02:41:46 2010 From: george.dma at gmail.com (George H) Date: Thu, 25 Feb 2010 11:41:46 +0200 Subject: [Rxtx] Lingering rxtx process In-Reply-To: <73a89f361002230029w4a9ec14bt56d654e43c1c9623@mail.gmail.com> References: <73a89f361002230029w4a9ec14bt56d654e43c1c9623@mail.gmail.com> Message-ID: With Mariusz Dec help and with the help of the threads that were mentioned http://mailman.qbang.org/pipermail/rxtx/2009-November/5790326.html http://embeddedfreak.wordpress.com/2008/10/08/rxtx-serial-port-helper/ I managed to solved my problem. I didn't really like it so much. I am not using the InputStream.read(byte[], int, int) method as for me I can break out of reading the stream if I get a '\n' or a 0x00. Either way the below code sample works for me. int data = 0; int len = 0; while(true) { data = commReader.getInputStream().read(); if(data == -1 || data == 0x00 || data == '\n' || commReader.getInputStream().available() < 1) { break; } if(len == buffer.length) { processData(buffer); clearBuffer(); } buffer[len++] = (byte)data; } Before I would loop the while until data != -1. But that blocks on .close() and my program never gets to exit. Adding .available() < 1 as a break condition fixes it when I call .close() I am going to see if this is a linux kernel configuration issue or not cos it isn't so obvious and I hardly ever use .available() when reading streams. Love the project though :) -- George H george.dma at gmail.com On Tue, Feb 23, 2010 at 10:29 AM, Mariusz Dec wrote: > > > 2010/2/22 George H > > Hi, >> >> I am using RXTX v2.1-7. >> I use it to communicate with 2 serial receipt printers and 1 serial line >> display device. My program runs well using the RXTX library on Windows and >> Linux. >> But... when I installed Linux on another hardware the program does not >> exit properly. By this I mean that the java program seems to have exited >> (passed the System.exit(0)) code but the console still does not return to >> the bash shell. >> >> Thread in Noember 2009' - > > http://mailman.qbang.org/pipermail/rxtx/2009-November/5778408.html > > I have disocvered one technique which solved this problem in Linux Ubuntu > and Mac for RXTX pre2.2, but should helps in 2.1.7 as well. > > Regards > Mariusz > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 01:02:21 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 13:32:21 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> My serial port driver(apparently) does not support receive timeout.I registered an event listener for DATA_AVAILABLE. However, the control never seems to come out of the 'while' loop.Shouldn't the InputStream.read return a '-1' immediately if no data is available (this seems to be the default operation)? This was tried on a x86 Linux desktop using rxtx-2.1-7 I've added the snippet for clarity: /******************************************************************************************************************************************************************************/ mySerialPort.enableReceiveThreshold(2000);//Trying to set a time limit for read calls System.out.println(mySerialPort.isReceiveTimeoutEnabled()); // I get FALSE, so its not supported on hardware. mySerialPort.addEventListener(this); mySerialPort.notifyOnDataAvailable(true);//register a event with //my SerialEvent listener implementation: public void serialEvent(SerialPortEvent arg0) { int newData=0; switch(arg0.getEventType()){ case SerialPortEvent.DATA_AVAILABLE: while (newData != -1) { try { newData = is.read();//This should eventually return a -1 if no data is available within a timeout.PROBLEM!! System.out.println("Got a byte from port:"+newData); if (newData == -1) { break; } } catch (IOException ex) { System.err.println(ex); return; } } break; } return; } /******************************************************************************************************************************************************************************/ Thanks and regards, Ravi From michael.erskine at ketech.com Wed Feb 3 02:26:50 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 09:26:50 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From michael.erskine at ketech.com Wed Feb 3 05:03:30 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 12:03:30 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > Michael Erskine > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > > Your event handler should handle the event and return immediately so that its > controlling thread can handle other events. I recommend a single read in the > following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) > reads all available bytes up to the size of the buffer returning the number of > bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } After posting this I considered the glaring possibility of the rawbuf read buffer being too small to receive all the available bytes and perhaps skipping data: after all, I'm guessing that is why we see so many posts asking for help with blocking implementations of read event handlers looping on "while(bytes are available)". I've spent this morning writing an extensive multi-threaded unit test suite that includes tests with a tiny buffer compared to the amount of data available and found that no data was being skipped. I now want to know why! The SerialPortEvent.DATA_AVAILABLE event must be being fired again if there is more data available on the input stream. If that is the case then it should be heavily documented with good examples in the wiki to avoid the types of developer anguish we see so regularly. BTW: I'm not at liberty to post the JUnit tests as they use my company's unit test suite framework. Regards, Michael Erskine. From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 06:18:04 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 18:48:04 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Hello Michael, I tried out your suggestion but the problem is that the read(rawbuf) blocks until the entire length of the rawbuf array has been read (blocking). I cannot decide on a reasonable size of the array because it varies from 2 bytes to as much as 50 byes (i'm communicating with a modem,each response is of a different length), which is why i wanted to use non blocking calls. But on a side note, read(byte[]) in turn calls the read() in a loop.In the native C function, the read is supposed to return a -1 upon timeout.But my driver does not support timeout.The default timeout value is zero and the linux select call upon zero time out causes an infinite wait.What am i missing...... Thanks and regards, Ravi Date: Wed, 3 Feb 2010 09:26:50 +0000 From: Michael Erskine To: "rxtx at qbang.org" Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: Content-Type: text/plain; charset="us-ascii" > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From m.kirkland at comcast.net Wed Feb 3 06:46:03 2010 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 3 Feb 2010 05:46:03 -0800 Subject: [Rxtx] One port blocking another port In-Reply-To: References: Message-ID: <68768633814F4D7D86761D34F0764FE0@bengal.net> It turns out this is caused by having the RTS/CTS flow control turned on and me not providing a true on the RTS pin. Somehow it seems the port timing out on a read allows the write to proceed. This is not an issue for my application but I wonder if the write should not proceed until the RTS pin is true even if a read times out. mk -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Monday, January 25, 2010 7:48 PM To: Mike Kirkland Cc: rxtx at qbang.org Subject: Re: [Rxtx] One port blocking another port On Mon, 25 Jan 2010, Mike Kirkland wrote: > > Hi All, > > ? > > I have a program that reads from one com port and writes to another com > port. It also does the same thing in reverse (reads from the second com port > and writes to the first one. It basically ties two com ports together. > > ? > > One port is very chatty and has a consent stream of data. The other port has > very little data. > > ? > > Both ports use a 5000 ms (5 second) time out. > > ? > > The issue I am having is that is appears that the first port?s write to the > second port is blocked while the second port is waiting for input. The first > port?s write proceeds only after the second port has timed out. > > ? > > I suppose I could have something twisted around in my code but I was > wondering if this is a know issue? > Hi Kirk, I've not seen a report like this. Perhaps some simple reproduction code will reveal a problem on your end or help us identify a problem in rxtx. I think there are several users doing multiport communication. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Wed Feb 3 07:03:58 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:03:58 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Message-ID: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> 2010/2/3 Ravishankar N > Hello Michael, > [..] > But on a side note, read(byte[]) in turn calls the read() in a loop.In the > native C function, the read is supposed to return a -1 upon timeout.But my > driver > does not support timeout.The default timeout value is zero and the linux > select call upon zero time out causes an infinite wait.What am i > missing...... > > When I have tested RXTX between platforms, I have observed "hangup" inside JNI driver when no data in Linux, is normal thing. Solution was setting the timeout for RXTX when no data from JNI driver. Something like that: commPort.enableReceiveTimeout(10); And it works perfect.... The only difference is that I am NOT using events - I am using continous read in separate thread and if data is available, is parsed and transferred to application using exception. Regards Mariusz > Thanks and regards, > Ravi > > Date: Wed, 3 Feb 2010 09:26:50 +0000 > From: Michael Erskine > To: "rxtx at qbang.org" > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > Message-ID: > > > Content-Type: text/plain; charset="us-ascii" > > > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of > > Ravishankar N > > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > > > My serial port driver(apparently) does not support receive timeout.I > > registered an event listener for DATA_AVAILABLE. However, the control > never > > seems to come out of the 'while' loop.Shouldn't the > > InputStream.read return a '-1' immediately if no data is available (this > seems > > to be the default operation)? > > Your event handler should handle the event and return immediately so that > its controlling thread can handle other events. I recommend a single read in > the following manner: rawbuf is a byte[] of "reasonable" size and the > read(byte[]) reads all available bytes up to the size of the buffer > returning the number of bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } > > This style of reading has worked for me with RXTX on Linux and Windows XP > for a good few years now in railway industry communications systems. Any > timeouts (largely unnecessary in my applications) can be handled elsewhere, > usually at a higher layer. > > Regards, > Michael Erskine. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Feb 3 07:22:55 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 3 Feb 2010 09:22:55 -0500 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: I'm guessing that this is driver specific. I recently had to support a select()/poll() infrastructure for a linux serial DD, its certainly non trivial to support async IO, so I suspect the problem in this case has to do with missing poll infrastructure in the device driver. This also has to coupled with special open flags for the device (which is within the rxtx code) The key routines within a 2.6 kernel linux device driver are shown below (if you have access to it for your particular device) are indicated below (here is a snippet from my device driver c code that supports polling/select). User space code to test this shown below also, note that the device needs to be opened with the O_NONBLOCK option to support the select/poll api // device driver code ..... /* * File operations supported by this driver. */ static struct file_operations iop_fops = { .owner = THIS_MODULE, .check_flags= iop_check_flags, .ioctl = iop_ioctl, .open = iop_open, .poll = iop_poll, // SUPPORT FOR SELECT/POLL infrastructure .read = iop_read, .release = iop_release, .write = iop_write, }; /** * Select/poll/epoll infrastructure. * * @param file * @param wait * * @return */ static unsigned int iop_poll(struct file *filp, poll_table *wait) { struct iop_device *devp = (struct iop_device *)filp->private_data; // the poll_table wait arg is an opaque pointer poll_wait(filp, &devp->readq, wait); // return from poll indicating whether we have read/write data unsigned int mask = 0; if (kfifo_len(devp->rx_fifo)) { mask |= (POLLIN | POLLRDNORM); } // @JC We don't do select on write yet // if (kfifo_len(devp->tx_fifo)) { // mask |= (POLLOUT | POLLWRNORM); // } // Only print out while debugging // if (mask != 0) { // printk (KERN_INFO "%s: [%04x]\n", __FUNCTION__, mask); // } return mask; } /** * device driver blocking and non blocking read function. This * function reads the requested number of bytes from the read * kfifo blocking as required. * * @param filp * @param buf * @param count * @param f_pos * * @return */ static ssize_t iop_read(struct file *filp, char __user *buf, size_t count, loff_t * ppos) { // access appropriate device struct struct iop_device *devp = (struct iop_device *) filp->private_data; ssize_t retval; // support non blocking mode (default) by checking if the kfifo is empty first if ((kfifo_len(devp->rx_fifo)==0) && (filp->f_flags & O_NONBLOCK)) { return -EAGAIN; } // wait for rx_fifo to receive data via receive interrupts retval = wait_event_interruptible(devp->readq, kfifo_len(devp->rx_fifo) != 0); // check for some error condition if (retval) { printk (KERN_ERR "%s: wait_event_interruptible returned[%d]\n", __FUNCTION__, retval); return retval; } // copy max requested bytes from rx_fifo to device buffer // this may still leave bytes in the kfifo for a subsequent read // if we are reading in a loop retval = kfifo_get(devp->rx_fifo, devp->rxbuf, count); // printk (KERN_INFO "%s: [%d] byte(s)\n", __FUNCTION__, retval); if (copy_to_user(buf, devp->rxbuf, retval)) { printk (KERN_ERR "%s: problem copying rx_fifo data to user buffer\n", __FUNCTION__); return -EFAULT; } return retval; } // a selection of my user space code reading via select()/poll()..... // user space open code iop_fd = ::open( deviceName.data(), O_RDWR | O_NONBLOCK); while ((bytes_to_expect - bytes_read) > 0) { // must reinitialize these between select calls fd_set readfds; FD_ZERO( &readfds ); FD_SET( iop_fd, &readfds ); // 1s sec read polling timeout struct timeval timeout; timeout.tv_sec = 1; timeout.tv_usec = 0; int rc = select( FD_SETSIZE, &readfds, NULL, NULL, &timeout ); // read from file when descriptor // indicates data available without blocking if ((rc > 0) && FD_ISSET(iop_fd, &readfds)) { // read into the appropriate offset within the rx_buf int temp = read(iop_fd, rx_buf + bytes_read, bytes_to_expect - bytes_read); if (!temp) { printf("EOF detected with %d bytes expected\n", bytes_to_expect - bytes_read); } else { bytes_read += temp; } } else if (rc < 0){ printf("%s: select on [%s], bytes_read[%d], errno=%d\n", __FUNCTION__, thread_args->device, bytes_read, errno); } else { printf("%s: select on [%s], bytes_read[%d], timeout\n", __FUNCTION__, thread_args->device, bytes_read); } } On Wed, Feb 3, 2010 at 9:03 AM, Mariusz Dec wrote: > > > 2010/2/3 Ravishankar N > >> Hello Michael, >> [..] >> >> But on a side note, read(byte[]) in turn calls the read() in a loop.In the >> native C function, the read is supposed to return a -1 upon timeout.But my >> driver >> does not support timeout.The default timeout value is zero and the linux >> select call upon zero time out causes an infinite wait.What am i >> missing...... >> >> > When I have tested RXTX between platforms, I have observed "hangup" inside > JNI driver when no data in Linux, is normal thing. > > Solution was setting the timeout for RXTX when no data from JNI driver. > > Something like that: > > commPort.enableReceiveTimeout(10); > > And it works perfect.... > > The only difference is that I am NOT using events - I am using continous > read in separate thread and if data is available, is parsed and transferred > to application using exception. > > Regards > Mariusz > > > >> Thanks and regards, >> Ravi >> >> Date: Wed, 3 Feb 2010 09:26:50 +0000 >> From: Michael Erskine >> To: "rxtx at qbang.org" >> Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? >> Message-ID: >> >> >> Content-Type: text/plain; charset="us-ascii" >> >> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >> Of >> > Ravishankar N >> > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? >> > >> > My serial port driver(apparently) does not support receive timeout.I >> > registered an event listener for DATA_AVAILABLE. However, the control >> never >> > seems to come out of the 'while' loop.Shouldn't the >> > InputStream.read return a '-1' immediately if no data is available (this >> seems >> > to be the default operation)? >> >> Your event handler should handle the event and return immediately so that >> its controlling thread can handle other events. I recommend a single read in >> the following manner: rawbuf is a byte[] of "reasonable" size and the >> read(byte[]) reads all available bytes up to the size of the buffer >> returning the number of bytes actually read... >> >> case SerialPortEvent.DATA_AVAILABLE: >> try { >> int i = is.read(rawbuf); >> if (i == -1) { >> << process EOF condition - should never happen >> >> return; >> } >> << process bytes (rawbuf, i); >> >> return; >> } catch (IOException e) { >> << promptly deal with exception >> >> return; >> } >> >> This style of reading has worked for me with RXTX on Linux and Windows XP >> for a good few years now in railway industry communications systems. Any >> timeouts (largely unnecessary in my applications) can be handled elsewhere, >> usually at a higher layer. >> >> Regards, >> Michael Erskine. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Feb 3 07:33:27 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:33:27 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: <73a89f361002030633j682610afia48dc7accd8e049b@mail.gmail.com> 2010/2/3 John Coffey > I'm guessing that this is driver specific. I recently had to support a > select()/poll() infrastructure for a linux serial DD, its certainly non > trivial to support async IO, so I suspect the problem in this case has to do > with missing poll infrastructure in the device driver. This also has to > coupled with special open flags for the device (which is within the rxtx > code) > > Yes, you are right, it may be driver specific, but in my case I haven't changed blocking JNI driver. I have added ONLY one call to RXTX method mentioned in my previous post and blocking (as seen as from Java app) gone out... Maybe this is not elegant, but works without problem in my app. I am using only FTDI chips and their drivers from couple of years and maybe this is the kind of the way to have no many problems with serial as well? Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From andyrxtx at g0poy.co.uk Wed Feb 3 11:09:04 2010 From: andyrxtx at g0poy.co.uk (andyrxtx at g0poy.co.uk) Date: Wed, 3 Feb 2010 18:09:04 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes Message-ID: <20100203180904.164f24dd@workstation.site> ?Hello RXTX group, I have just joined this group, and this is my first posting. I wanted to pass on some information regarding rxtx, so apologies if this has been brought up before. I have searched back through the archives but nothing specific came up. I am not a Java programmer, and I only came across rxtx a few days ago. I use a piece of test equipment called a miniVNA http://www.miniradiosolutions.com/ This is a serial USB controlled instrument, and it has control software available for MS windows, and a very old and now non-working Linux application. A few days ago Dietmar, DL2SBA released a Java application to control the miniVNA, obviously this application makes use of rxtx. The program worked fine on Windows, so I set about installing it onto Linux. I use SUSE11.1 After a few false starts, I got the system running fairly easily, sorting out the file locking by adding the uucp group to the users account as suggested (I used the 2.2pre binary files) I then passed the install instructions onto another miniVNA user, who also uses SUSE, but he ran into problems. To cut a long story short, he was also having file lock problems, but the uucp fix did not work. Digging into his system I found that there have been some changes in SUSE 11.2. tty ports are now assigned to the dialout group rather than uucp. A hint in the rxtx INSTALL file, suggested that var/lock needs to be checked, so: SUSE 11.1, var/lock is root:uucp SUSE 11.2 var/lock is root:root A search on Google brought up several comments regarding this, and also a bugzilla entry. https://bugzilla.novell.com/show_bug.cgi?id=552095 However from reading the various posts, some of which are in the bugzilla entry, it appears that many distros may be, or have changed to this configuration, and this will undoubtedly break several things, rxtx included. I solved my fellow SUSE users problem by compiling the rxtx libs with the no lock file option during configure, and that solved his problem. As this issue will probably take some time to get resolved across all the various Linux distros, it might be worth considering changing the default on the Linux build of rxtx not to use lockfiles, or provide the two versions of the lib in the binary archive. Thanks for your indulgence Andy From damorales at gmail.com Wed Feb 3 11:33:23 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 15:33:23 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203180904.164f24dd@workstation.site> References: <20100203180904.164f24dd@workstation.site> Message-ID: Hi I had the same problem in Mandriva 2010 and yes, adding the user to the uucp group did not work as it used to be in earlier versions of linux distros, causing RXTX to not work as non root user. The problem appears because the existense of UDEV, now you MUST add a RULE so the group (uucp or whatever) have access (Read, Write, Execute) to the Serial Port. To solve the problem, without needing to recompile RXTX, you must add a rule to grant permissions (0666) to the group for the device or port (tty*, ttyUSB*, etc). I do not remember now what is the line i added but when i come back home i will give it to you (i am at work now). Greetings ! 2010/2/3 > Hello RXTX group, > > I have just joined this group, and this is my first posting. > I wanted to pass on some information regarding rxtx, so apologies if > this has been brought up before. I have searched back through the > archives but nothing specific came up. > > I am not a Java programmer, and I only came across rxtx a few days ago. > > I use a piece of test equipment called a miniVNA > http://www.miniradiosolutions.com/ > > This is a serial USB controlled instrument, and it has control software > available for MS windows, and a very old and now non-working Linux > application. > > A few days ago Dietmar, DL2SBA released a Java application to control the > miniVNA, obviously this application makes use of rxtx. > > The program worked fine on Windows, so I set about installing it onto > Linux. I use SUSE11.1 After a few false starts, I got the system running > fairly easily, sorting out the file locking by adding the uucp group to > the users account as suggested (I used the 2.2pre binary files) I then > passed the install instructions onto another miniVNA user, who also uses > SUSE, but he ran into problems. To cut a long story short, he was > also having file lock problems, but the uucp fix did not work. Digging > into his system I found that there have been some changes in SUSE 11.2. > > tty ports are now assigned to the dialout group rather than uucp. > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > checked, so: > > SUSE 11.1, var/lock is root:uucp > SUSE 11.2 var/lock is root:root > > A search on Google brought up several comments regarding this, and also > a bugzilla entry. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > However from reading the various posts, some of which are in the bugzilla > entry, it appears that many distros may be, or have changed to this > configuration, and this will undoubtedly break several things, rxtx > included. > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > no lock file option during configure, and that solved his problem. > > As this issue will probably take some time to get resolved across all the > various Linux distros, it might be worth considering changing the default > on the Linux build of rxtx not to use lockfiles, or provide the two > versions of the lib in the binary archive. > > Thanks for your indulgence > > Andy > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Wed Feb 3 12:07:02 2010 From: andy at g0poy.com (Andy Eskelson) Date: Wed, 3 Feb 2010 19:07:02 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> Message-ID: <20100203190702.1b0e7015@workstation.site> Thanks Daniel, I am aware of the permissions problem, I have had a udev rules to solve this for other programs for some time. . I don't think that this is the same problem. as far as I can understand things, the lock files are written in var/lock. Previously var/lock and dev/tty-whatever were the same group. Now with var/lock owned by and with a group of root:root anything other than root cannot create a lock file. Even minicom is broken by this change. This change is going to have quite a few knock-on effects I think. Andy On Wed, 3 Feb 2010 15:33:23 -0300 Daniel Morales Salas wrote: > Hi > > I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > group did not work as it used to be in earlier versions of linux distros, > causing RXTX to not work as non root user. > > The problem appears because the existense of UDEV, now you MUST add a RULE > so the group (uucp or whatever) have access (Read, Write, Execute) to the > Serial Port. > > To solve the problem, without needing to recompile RXTX, you must add a rule > to grant permissions (0666) to the group for the device or port (tty*, > ttyUSB*, etc). I do not remember now what is the line i added but when i > come back home i will give it to you (i am at work now). > > Greetings ! > > 2010/2/3 > > > Hello RXTX group, > > > > I have just joined this group, and this is my first posting. > > I wanted to pass on some information regarding rxtx, so apologies if > > this has been brought up before. I have searched back through the > > archives but nothing specific came up. > > > > I am not a Java programmer, and I only came across rxtx a few days ago. > > > > I use a piece of test equipment called a miniVNA > > http://www.miniradiosolutions.com/ > > > > This is a serial USB controlled instrument, and it has control software > > available for MS windows, and a very old and now non-working Linux > > application. > > > > A few days ago Dietmar, DL2SBA released a Java application to control the > > miniVNA, obviously this application makes use of rxtx. > > > > The program worked fine on Windows, so I set about installing it onto > > Linux. I use SUSE11.1 After a few false starts, I got the system running > > fairly easily, sorting out the file locking by adding the uucp group to > > the users account as suggested (I used the 2.2pre binary files) I then > > passed the install instructions onto another miniVNA user, who also uses > > SUSE, but he ran into problems. To cut a long story short, he was > > also having file lock problems, but the uucp fix did not work. Digging > > into his system I found that there have been some changes in SUSE 11.2. > > > > tty ports are now assigned to the dialout group rather than uucp. > > > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > checked, so: > > > > SUSE 11.1, var/lock is root:uucp > > SUSE 11.2 var/lock is root:root > > > > A search on Google brought up several comments regarding this, and also > > a bugzilla entry. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > However from reading the various posts, some of which are in the bugzilla > > entry, it appears that many distros may be, or have changed to this > > configuration, and this will undoubtedly break several things, rxtx > > included. > > > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > > no lock file option during configure, and that solved his problem. > > > > As this issue will probably take some time to get resolved across all the > > various Linux distros, it might be worth considering changing the default > > on the Linux build of rxtx not to use lockfiles, or provide the two > > versions of the lib in the binary archive. > > > > Thanks for your indulgence > > > > Andy > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From thisdyingdream at gmail.com Wed Feb 3 12:32:35 2010 From: thisdyingdream at gmail.com (Steven Harms) Date: Wed, 3 Feb 2010 14:32:35 -0500 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203190702.1b0e7015@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: This is currently a bug in OpenSUSE that affects more than just rxtx, and is a result of unified udev rules. You can work around this by making udev change the group back to uucp until something more happens. https://bugzilla.novell.com/show_bug.cgi?id=552095 Thanks, Steve On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > Thanks Daniel, > > I am aware of the permissions problem, I have had a udev rules to solve > this for other programs for some time. > . > I don't think that this is the same problem. as far as I can understand > things, the lock files are written in var/lock. Previously var/lock and > dev/tty-whatever were the same group. Now with var/lock owned by and with > a group of root:root anything other than root cannot create a lock > file. Even minicom is broken by this change. > > This change is going to have quite a few knock-on effects I think. > > > Andy > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > Daniel Morales Salas wrote: > >> Hi >> >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp >> group did not work as it used to be in earlier versions of linux distros, >> causing RXTX to not work as non root user. >> >> The problem appears because the existense of UDEV, now you MUST add a RULE >> so the group (uucp or whatever) have access (Read, Write, Execute) to the >> Serial Port. >> >> To solve the problem, without needing to recompile RXTX, you must add a rule >> to grant permissions (0666) to the group for the device or port (tty*, >> ttyUSB*, etc). I do not remember now what is the line i added but when i >> come back home i will give it to you (i am at work now). >> >> Greetings ! >> >> 2010/2/3 >> >> > Hello RXTX group, >> > >> > I have just joined this group, and this is my first posting. >> > I wanted to pass on ?some information regarding rxtx, so apologies if >> > this has been brought up before. I have searched back through the >> > archives but nothing specific came up. >> > >> > I am not a Java programmer, and I only came across rxtx a few days ago. >> > >> > I use a piece of test equipment called a miniVNA >> > http://www.miniradiosolutions.com/ >> > >> > This is a serial USB controlled instrument, and it has control software >> > available for MS windows, and a very old and now non-working Linux >> > application. >> > >> > A few days ago Dietmar, DL2SBA released a Java application to control the >> > miniVNA, obviously this application makes use of rxtx. >> > >> > The program worked fine on Windows, so I set about installing it onto >> > Linux. I use SUSE11.1 After a few false starts, I got the system running >> > fairly easily, sorting out the file locking by adding the uucp group to >> > the users account as suggested (I used the 2.2pre binary files) I then >> > passed the install instructions onto another miniVNA user, who also uses >> > SUSE, but he ran into problems. To cut a long story short, he was >> > also having file lock problems, but the uucp fix did not work. Digging >> > into his system I found that there have been some changes in SUSE 11.2. >> > >> > tty ports are now assigned to the dialout group rather than uucp. >> > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be >> > checked, so: >> > >> > SUSE 11.1, var/lock is root:uucp >> > SUSE 11.2 var/lock is root:root >> > >> > A search on Google brought up several comments regarding this, and also >> > a ?bugzilla entry. >> > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 >> > >> > However from reading the various posts, some of which are in the bugzilla >> > entry, it appears that many distros may be, or have changed to this >> > configuration, and this will undoubtedly break several things, rxtx >> > included. >> > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the >> > no lock file option during configure, and that solved his problem. >> > >> > As this issue will probably take some time to get resolved across all the >> > various Linux distros, it might be worth considering changing the default >> > on the Linux build of rxtx not to use lockfiles, or provide the two >> > versions of the lib in the binary archive. >> > >> > Thanks for your indulgence >> > >> > Andy >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> >> >> >> -- >> Atte: >> Daniel Dario Morales Salas >> Ingeniero Civil en Computaci?n e Inform?tica >> Tel?fono: 02 684 3417 >> Celular: 09 643 1802 >> Santiago, Chile > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 WWW: http://www.sharms.org/blog From andy at g0poy.com Wed Feb 3 17:58:29 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 00:58:29 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: <20100204005829.7dc944e1@workstation.site> Thanks Steve, changing the serial ports back the uucp is not a big problem. I have a udev rule that can be easily modified already. However I cannot see any way of dealing with the var/lock problem apart from making it writable to all. Any thoughts? Andy On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms wrote: > This is currently a bug in OpenSUSE that affects more than just rxtx, > and is a result of unified udev rules. You can work around this by > making udev change the group back to uucp until something more > happens. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > Thanks, > > Steve > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > Thanks Daniel, > > > > I am aware of the permissions problem, I have had a udev rules to solve > > this for other programs for some time. > > . > > I don't think that this is the same problem. as far as I can understand > > things, the lock files are written in var/lock. Previously var/lock and > > dev/tty-whatever were the same group. Now with var/lock owned by and with > > a group of root:root anything other than root cannot create a lock > > file. Even minicom is broken by this change. > > > > This change is going to have quite a few knock-on effects I think. > > > > > > Andy > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > Daniel Morales Salas wrote: > > > >> Hi > >> > >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > >> group did not work as it used to be in earlier versions of linux distros, > >> causing RXTX to not work as non root user. > >> > >> The problem appears because the existense of UDEV, now you MUST add a RULE > >> so the group (uucp or whatever) have access (Read, Write, Execute) to the > >> Serial Port. > >> > >> To solve the problem, without needing to recompile RXTX, you must add a rule > >> to grant permissions (0666) to the group for the device or port (tty*, > >> ttyUSB*, etc). I do not remember now what is the line i added but when i > >> come back home i will give it to you (i am at work now). > >> > >> Greetings ! > >> > >> 2010/2/3 > >> > >> > Hello RXTX group, > >> > > >> > I have just joined this group, and this is my first posting. > >> > I wanted to pass on ?some information regarding rxtx, so apologies if > >> > this has been brought up before. I have searched back through the > >> > archives but nothing specific came up. > >> > > >> > I am not a Java programmer, and I only came across rxtx a few days ago. > >> > > >> > I use a piece of test equipment called a miniVNA > >> > http://www.miniradiosolutions.com/ > >> > > >> > This is a serial USB controlled instrument, and it has control software > >> > available for MS windows, and a very old and now non-working Linux > >> > application. > >> > > >> > A few days ago Dietmar, DL2SBA released a Java application to control the > >> > miniVNA, obviously this application makes use of rxtx. > >> > > >> > The program worked fine on Windows, so I set about installing it onto > >> > Linux. I use SUSE11.1 After a few false starts, I got the system running > >> > fairly easily, sorting out the file locking by adding the uucp group to > >> > the users account as suggested (I used the 2.2pre binary files) I then > >> > passed the install instructions onto another miniVNA user, who also uses > >> > SUSE, but he ran into problems. To cut a long story short, he was > >> > also having file lock problems, but the uucp fix did not work. Digging > >> > into his system I found that there have been some changes in SUSE 11.2. > >> > > >> > tty ports are now assigned to the dialout group rather than uucp. > >> > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > >> > checked, so: > >> > > >> > SUSE 11.1, var/lock is root:uucp > >> > SUSE 11.2 var/lock is root:root > >> > > >> > A search on Google brought up several comments regarding this, and also > >> > a ?bugzilla entry. > >> > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > >> > > >> > However from reading the various posts, some of which are in the bugzilla > >> > entry, it appears that many distros may be, or have changed to this > >> > configuration, and this will undoubtedly break several things, rxtx > >> > included. > >> > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the > >> > no lock file option during configure, and that solved his problem. > >> > > >> > As this issue will probably take some time to get resolved across all the > >> > various Linux distros, it might be worth considering changing the default > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > >> > versions of the lib in the binary archive. > >> > > >> > Thanks for your indulgence > >> > > >> > Andy > >> > > >> > _______________________________________________ > >> > Rxtx mailing list > >> > Rxtx at qbang.org > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > >> > >> > >> > >> -- > >> Atte: > >> Daniel Dario Morales Salas > >> Ingeniero Civil en Computaci?n e Inform?tica > >> Tel?fono: 02 684 3417 > >> Celular: 09 643 1802 > >> Santiago, Chile > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > WWW: http://www.sharms.org/blog From damorales at gmail.com Wed Feb 3 18:26:38 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 22:26:38 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100204005829.7dc944e1@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: Hello I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva 2010 this is what i get: drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ and i don't have ANY problem with lock files and RXTX in my java software. All i had to do was add this rule to udev: # serial KERNEL=="tty*", GROUP="uucp", MODE="0666" and that was all. Of course my user (metalklesk) is part of uucp group. I did not make /var/lock writable to all users. Greetings ! 2010/2/3 Andy Eskelson > Thanks Steve, > > changing the serial ports back the uucp is not a big problem. I have a > udev rule that can be easily modified already. However I cannot see any > way of dealing with the var/lock problem apart from making it writable to > all. Any thoughts? > > Andy > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > wrote: > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > and is a result of unified udev rules. You can work around this by > > making udev change the group back to uucp until something more > > happens. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > Thanks, > > > > Steve > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > Thanks Daniel, > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > this for other programs for some time. > > > . > > > I don't think that this is the same problem. as far as I can understand > > > things, the lock files are written in var/lock. Previously var/lock and > > > dev/tty-whatever were the same group. Now with var/lock owned by and > with > > > a group of root:root anything other than root cannot create a lock > > > file. Even minicom is broken by this change. > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > Daniel Morales Salas wrote: > > > > > >> Hi > > >> > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > the uucp > > >> group did not work as it used to be in earlier versions of linux > distros, > > >> causing RXTX to not work as non root user. > > >> > > >> The problem appears because the existense of UDEV, now you MUST add a > RULE > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > the > > >> Serial Port. > > >> > > >> To solve the problem, without needing to recompile RXTX, you must add > a rule > > >> to grant permissions (0666) to the group for the device or port (tty*, > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > i > > >> come back home i will give it to you (i am at work now). > > >> > > >> Greetings ! > > >> > > >> 2010/2/3 > > >> > > >> > Hello RXTX group, > > >> > > > >> > I have just joined this group, and this is my first posting. > > >> > I wanted to pass on some information regarding rxtx, so apologies > if > > >> > this has been brought up before. I have searched back through the > > >> > archives but nothing specific came up. > > >> > > > >> > I am not a Java programmer, and I only came across rxtx a few days > ago. > > >> > > > >> > I use a piece of test equipment called a miniVNA > > >> > http://www.miniradiosolutions.com/ > > >> > > > >> > This is a serial USB controlled instrument, and it has control > software > > >> > available for MS windows, and a very old and now non-working Linux > > >> > application. > > >> > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > control the > > >> > miniVNA, obviously this application makes use of rxtx. > > >> > > > >> > The program worked fine on Windows, so I set about installing it > onto > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > running > > >> > fairly easily, sorting out the file locking by adding the uucp group > to > > >> > the users account as suggested (I used the 2.2pre binary files) I > then > > >> > passed the install instructions onto another miniVNA user, who also > uses > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > >> > also having file lock problems, but the uucp fix did not work. > Digging > > >> > into his system I found that there have been some changes in SUSE > 11.2. > > >> > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > >> > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > >> > checked, so: > > >> > > > >> > SUSE 11.1, var/lock is root:uucp > > >> > SUSE 11.2 var/lock is root:root > > >> > > > >> > A search on Google brought up several comments regarding this, and > also > > >> > a bugzilla entry. > > >> > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > >> > > > >> > However from reading the various posts, some of which are in the > bugzilla > > >> > entry, it appears that many distros may be, or have changed to this > > >> > configuration, and this will undoubtedly break several things, rxtx > > >> > included. > > >> > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > with the > > >> > no lock file option during configure, and that solved his problem. > > >> > > > >> > As this issue will probably take some time to get resolved across > all the > > >> > various Linux distros, it might be worth considering changing the > default > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > >> > versions of the lib in the binary archive. > > >> > > > >> > Thanks for your indulgence > > >> > > > >> > Andy > > >> > > > >> > _______________________________________________ > > >> > Rxtx mailing list > > >> > Rxtx at qbang.org > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > >> > > > >> > > >> > > >> > > >> -- > > >> Atte: > > >> Daniel Dario Morales Salas > > >> Ingeniero Civil en Computaci?n e Inform?tica > > >> Tel?fono: 02 684 3417 > > >> Celular: 09 643 1802 > > >> Santiago, Chile > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at qbang.org > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > -- > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > WWW: http://www.sharms.org/blog > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Thu Feb 4 05:31:46 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 12:31:46 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: <20100204123146.6cffeb67@workstation.site> Thank's for the confirmation. Something odd is going on somewhere in SUSE 11.2. I'll have to build up a local SUSE11.2 system to see if I can nail down exactly what is going on. Something is blocking the lockfiles in var/lock. The net is nice, but it's a bit difficult trying to work out what is going on what the machine in question is in Germany and I'm in the UK :-) Andy On Wed, 3 Feb 2010 22:26:38 -0300 Daniel Morales Salas wrote: > Hello > > I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva > 2010 this is what i get: > > drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ > > and i don't have ANY problem with lock files and RXTX in my java software. > All i had to do was add this rule to udev: > > # serial > KERNEL=="tty*", GROUP="uucp", MODE="0666" > > and that was all. Of course my user (metalklesk) is part of uucp group. > I did not make /var/lock writable to all users. > > Greetings ! > > 2010/2/3 Andy Eskelson > > > Thanks Steve, > > > > changing the serial ports back the uucp is not a big problem. I have a > > udev rule that can be easily modified already. However I cannot see any > > way of dealing with the var/lock problem apart from making it writable to > > all. Any thoughts? > > > > Andy > > > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > > wrote: > > > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > > and is a result of unified udev rules. You can work around this by > > > making udev change the group back to uucp until something more > > > happens. > > > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > > > Thanks, > > > > > > Steve > > > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > > Thanks Daniel, > > > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > > this for other programs for some time. > > > > . > > > > I don't think that this is the same problem. as far as I can understand > > > > things, the lock files are written in var/lock. Previously var/lock and > > > > dev/tty-whatever were the same group. Now with var/lock owned by and > > with > > > > a group of root:root anything other than root cannot create a lock > > > > file. Even minicom is broken by this change. > > > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > > Daniel Morales Salas wrote: > > > > > > > >> Hi > > > >> > > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > > the uucp > > > >> group did not work as it used to be in earlier versions of linux > > distros, > > > >> causing RXTX to not work as non root user. > > > >> > > > >> The problem appears because the existense of UDEV, now you MUST add a > > RULE > > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > > the > > > >> Serial Port. > > > >> > > > >> To solve the problem, without needing to recompile RXTX, you must add > > a rule > > > >> to grant permissions (0666) to the group for the device or port (tty*, > > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > > i > > > >> come back home i will give it to you (i am at work now). > > > >> > > > >> Greetings ! > > > >> > > > >> 2010/2/3 > > > >> > > > >> > Hello RXTX group, > > > >> > > > > >> > I have just joined this group, and this is my first posting. > > > >> > I wanted to pass on some information regarding rxtx, so apologies > > if > > > >> > this has been brought up before. I have searched back through the > > > >> > archives but nothing specific came up. > > > >> > > > > >> > I am not a Java programmer, and I only came across rxtx a few days > > ago. > > > >> > > > > >> > I use a piece of test equipment called a miniVNA > > > >> > http://www.miniradiosolutions.com/ > > > >> > > > > >> > This is a serial USB controlled instrument, and it has control > > software > > > >> > available for MS windows, and a very old and now non-working Linux > > > >> > application. > > > >> > > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > > control the > > > >> > miniVNA, obviously this application makes use of rxtx. > > > >> > > > > >> > The program worked fine on Windows, so I set about installing it > > onto > > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > > running > > > >> > fairly easily, sorting out the file locking by adding the uucp group > > to > > > >> > the users account as suggested (I used the 2.2pre binary files) I > > then > > > >> > passed the install instructions onto another miniVNA user, who also > > uses > > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > > >> > also having file lock problems, but the uucp fix did not work. > > Digging > > > >> > into his system I found that there have been some changes in SUSE > > 11.2. > > > >> > > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > > >> > > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > > >> > checked, so: > > > >> > > > > >> > SUSE 11.1, var/lock is root:uucp > > > >> > SUSE 11.2 var/lock is root:root > > > >> > > > > >> > A search on Google brought up several comments regarding this, and > > also > > > >> > a bugzilla entry. > > > >> > > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > >> > > > > >> > However from reading the various posts, some of which are in the > > bugzilla > > > >> > entry, it appears that many distros may be, or have changed to this > > > >> > configuration, and this will undoubtedly break several things, rxtx > > > >> > included. > > > >> > > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > > with the > > > >> > no lock file option during configure, and that solved his problem. > > > >> > > > > >> > As this issue will probably take some time to get resolved across > > all the > > > >> > various Linux distros, it might be worth considering changing the > > default > > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > > >> > versions of the lib in the binary archive. > > > >> > > > > >> > Thanks for your indulgence > > > >> > > > > >> > Andy > > > >> > > > > >> > _______________________________________________ > > > >> > Rxtx mailing list > > > >> > Rxtx at qbang.org > > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > > >> > > > > >> > > > >> > > > >> > > > >> -- > > > >> Atte: > > > >> Daniel Dario Morales Salas > > > >> Ingeniero Civil en Computaci?n e Inform?tica > > > >> Tel?fono: 02 684 3417 > > > >> Celular: 09 643 1802 > > > >> Santiago, Chile > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at qbang.org > > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > > > -- > > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > > > WWW: http://www.sharms.org/blog > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From Bob_Jacobsen at lbl.gov Thu Feb 4 09:26:49 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Thu, 4 Feb 2010 08:26:49 -0800 Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 Message-ID: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're using RXTX-2.2pre2, although it emits the known message about "Version mismatch". WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 After the usual messing around, we've got it working on 11 Windows versions, multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ have things working rarely say so, so I don't know whether anybody has gotten it to work on 10.4 or not. The problem encountered is this: dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib dyld: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib followed by the JVM crashing hard. I've got those dump files if that would help. Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If so, is there a patch I can get and build? Thanks Bob -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From tjarvi at qbang.org Thu Feb 4 14:22:21 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 4 Feb 2010 14:22:21 -0700 (MST) Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 In-Reply-To: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> References: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> Message-ID: On Thu, 4 Feb 2010, Bob Jacobsen wrote: > We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're > using RXTX-2.2pre2, although it emits the known message about "Version > mismatch". > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > > After the usual messing around, we've got it working on 11 Windows versions, > multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with > a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ > have things working rarely say so, so I don't know whether anybody has gotten > it to work on 10.4 or not. > > The problem encountered is this: > > dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > dyld: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > followed by the JVM crashing hard. I've got those dump files if that would > help. > > Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If > so, is there a patch I can get and build? > Hi Bob, I talked to a coworker about the problem you ran into. It appears that it is possible to target 'older' Mac systems through makefile configuration changes. "Configuring a Makefile-Based Project If you have a makefile-based project, you can also take advantage of SDK-based development, by adding the appropriate options to your compile and link commands. Using SDKs in makefile-based projects requires GCC 4.0 or later. To choose an SDK, you use the -isysroot option with the compiler and the -syslibroot option with the linker. Both options require that you specify the full path to the desired SDK directory. To set the Deployment OS version in a makefile, use a makefile variable of the form: ENVP= MACOSX_DEPLOYMENT_TARGET=10.4. To use this variable in your makefile, include it in front of your compile and link commands." http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html Or build on the oldest system you want to support. -- Trent Jarvi tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Thu Feb 4 14:56:19 2010 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Thu, 4 Feb 2010 14:56:19 -0700 Subject: [Rxtx] RXTX on 64 Bit Redhat In-Reply-To: References: <4ec9eab61001281448g3dd84910r867619948a4e0d7a@mail.gmail.com> Message-ID: Trent -- Finally fixed all my build related issues. I ran into another issue. On one of my machines my JDK is returning multiple folders for the "java.ext.dirs" (java.ext.dirs -> /opt/jdk1.6.0_17/jre/lib/ext:/usr/java/packages/lib/ext) system property. As a result my JVM wasn't able to detect the gnu.io.rxtx.properties. I am attaching a patch for RXTXCommDriver.java file to check for multiple locations. Also i have to assign permission 660 to all my dev ports to be located by RXTX. Pawan ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 5:12 PM To: Trent Jarvi Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Here is the error i get when i build the src from release-2-1-7 -bash-3.2$ make ( \ \ cd i686-pc-linux-gnu; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/ jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I/opt/jav a1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec - c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialImp.lo;\ if [ "Serial" = "Serial" ]; then \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I /opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_tim espec -c /home/jb_stg/rxtx/rxtx-devel/./src/fuserImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ else \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo; \ fi; \ ) gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/inclu de -I/opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need _timespec -c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -fPIC -DPIC -o /hom e/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/.libs/SerialImp.o /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:25:29: error: gnu_io_RXTXPort.h: No such file or directory In file included from /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:113: /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:91: error: expected specifier-qua lifier-list before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'jobject' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:408: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:409: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:410: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:411: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:415: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:416: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:417: error: expected '=', ',', '; ', 'asm' or '__attribute__' before 'is_interrupted' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:418: error: expected declaration specifiers or '...' before 'jint' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:424: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:441: error: expected ')' before ' *' token ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 4:57 PM To: Santosh Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Santosh -- Thank you. That fixed the issue. All -- What CVS branch or release should i use to get the latest RXTX src code. Pawan ________________________________ From: Santosh [mailto:santosh.ry at gmail.com] Sent: Thursday, January 28, 2010 3:49 PM To: Kharbanda, Pawan Cc: Trent Jarvi; rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat error "./configure: /bin/sh^M: bad interpreter: No such file or directory". I think you need to run dos2unix on script files before compiling. Thanks, Santosh On Thu, Jan 28, 2010 at 5:33 PM, Kharbanda, Pawan > wrote: Trent -- We are upgrading our exisiting OS and JDK on a project that rely heavily on RXTX api's. We are now using JDK1.6 32 bit (build 1.6.0_17-b04) and RedHat 5 on a 64 bit machine. Linux tocrhstg02.dot.state.co.us 2.6.18-164.6.1.el5 #1 SMP Tue Oct 27 11:30:06 EDT 2009 i686 i686 i386 GNU/Linux Red Hat Enterprise Linux Server release 5.4 (Tikanga) I tried to run version 2.1.7 r2 on it but not able to see any of my Digi ports I was able to access only /dev/ttyS0 (physical ports). Not sure if the problem is with the Digi driver or RXTX. I tried to open a Digi port with minicom and it worked fine. I also tried to get latest from CVS (rxtx-devel) and when I do "configure" I see this error "./configure: /bin/sh^M: bad interpreter: No such file or directory". Can someone please help me with this? Thanks for the help. Pawan _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch.txt URL: From juan.vicente.l.g at gmail.com Sat Feb 13 04:44:17 2010 From: juan.vicente.l.g at gmail.com (Juan Vicente Lopez Gutierrez) Date: Sat, 13 Feb 2010 12:44:17 +0100 Subject: [Rxtx] RXTX in macmini OSX 10.5 Message-ID: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> Hello. My name is Juanvi and I'm from Spain. I tried to launch a software created by me in the library CXR java to send information through the serial port and I can not make it work. In windows if I've done but not mac. I have a mac mini with OSX 10.5 and have read in the list of web mail that you CXR if you have managed to make it work on that operating system. I need you help me please. Do I make the mistake that shows me java: run: Stable Library =============================== Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 gnu.io.PortInUseException: Unknow Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:26) at TwoWatSerialComm.main(TwoWaySerialComm.java:106) Experimental: JNI_OnLoad called. GENERACION CORRECTA (total time: 0 seconds) I do not have permission to access the serial port, do not know. Os agradeceria much to sit down. A greeting and thanks. Pardon my English. Juanvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From juan.vicente.l.g at gmail.com Sat Feb 13 14:39:41 2010 From: juan.vicente.l.g at gmail.com (Juan Vicente Lopez Gutierrez) Date: Sat, 13 Feb 2010 22:39:41 +0100 Subject: [Rxtx] Fwd: RXTX in macmini OSX 10.5 In-Reply-To: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> References: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> Message-ID: <29405e5c1002131339m2059d169sdc8549ed9706a1af@mail.gmail.com> ---------- Forwarded message ---------- From: Juan Vicente Lopez Gutierrez Date: 2010/2/13 Subject: RXTX in macmini OSX 10.5 To: rxtx at qbang.org Hello. My name is Juanvi and I'm from Spain. I tried to launch a software created by me in the library CXR java to send information through the serial port and I can not make it work. In windows if I've done but not mac. I have a mac mini with OSX 10.5 and have read in the list of web mail that you CXR if you have managed to make it work on that operating system. I need you help me please. Do I make the mistake that shows me java: run: Stable Library =============================== Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 gnu.io.PortInUseException: Unknow Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:26) at TwoWatSerialComm.main(TwoWaySerialComm.java:106) Experimental: JNI_OnLoad called. GENERACION CORRECTA (total time: 0 seconds) I do not have permission to access the serial port, do not know. Os agradeceria much to sit down. A greeting and thanks. Pardon my English. Juanvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Mon Feb 22 04:35:48 2010 From: george.dma at gmail.com (George H) Date: Mon, 22 Feb 2010 13:35:48 +0200 Subject: [Rxtx] Lingering rxtx process Message-ID: Hi, I am using RXTX v2.1-7. I use it to communicate with 2 serial receipt printers and 1 serial line display device. My program runs well using the RXTX library on Windows and Linux. But... when I installed Linux on another hardware the program does not exit properly. By this I mean that the java program seems to have exited (passed the System.exit(0)) code but the console still does not return to the bash shell. I have to CTRL+C each time to kill the program. And on each restart RXTX has to remove stale LCK files. Just note I am only getting this on one machine, if it makes any difference it is an i686 system with all VIA chipsets and VIA-C7M NannoBGA2 processor. Any ideas? Thanks -- George H george.dma at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Mon Feb 22 04:43:43 2010 From: george.dma at gmail.com (George H) Date: Mon, 22 Feb 2010 13:43:43 +0200 Subject: [Rxtx] Lingering rxtx process Message-ID: Hi, I am using RXTX v2.1-7. I use it to communicate with 2 serial receipt printers and 1 serial line display device. My program runs well using the RXTX library on Windows and Linux. But... when I installed Linux on another hardware the program does not exit properly. By this I mean that the java program seems to have exited (passed the System.exit(0)) code but the console still does not return to the bash shell. I have to CTRL+C each time to kill the program. And on each restart RXTX has to remove stale LCK files. Just note I am only getting this on one machine, if it makes any difference it is an i686 system with all VIA chipsets and VIA-C7M NannoBGA2 processor. Any ideas? Thanks -- George H george.dma at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Tue Feb 23 01:29:42 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Tue, 23 Feb 2010 09:29:42 +0100 Subject: [Rxtx] Lingering rxtx process In-Reply-To: References: Message-ID: <73a89f361002230029w4a9ec14bt56d654e43c1c9623@mail.gmail.com> 2010/2/22 George H > Hi, > > I am using RXTX v2.1-7. > I use it to communicate with 2 serial receipt printers and 1 serial line > display device. My program runs well using the RXTX library on Windows and > Linux. > But... when I installed Linux on another hardware the program does not exit > properly. By this I mean that the java program seems to have exited (passed > the System.exit(0)) code but the console still does not return to the bash > shell. > > Thread in Noember 2009' - http://mailman.qbang.org/pipermail/rxtx/2009-November/5778408.html I have disocvered one technique which solved this problem in Linux Ubuntu and Mac for RXTX pre2.2, but should helps in 2.1.7 as well. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Thu Feb 25 02:41:46 2010 From: george.dma at gmail.com (George H) Date: Thu, 25 Feb 2010 11:41:46 +0200 Subject: [Rxtx] Lingering rxtx process In-Reply-To: <73a89f361002230029w4a9ec14bt56d654e43c1c9623@mail.gmail.com> References: <73a89f361002230029w4a9ec14bt56d654e43c1c9623@mail.gmail.com> Message-ID: With Mariusz Dec help and with the help of the threads that were mentioned http://mailman.qbang.org/pipermail/rxtx/2009-November/5790326.html http://embeddedfreak.wordpress.com/2008/10/08/rxtx-serial-port-helper/ I managed to solved my problem. I didn't really like it so much. I am not using the InputStream.read(byte[], int, int) method as for me I can break out of reading the stream if I get a '\n' or a 0x00. Either way the below code sample works for me. int data = 0; int len = 0; while(true) { data = commReader.getInputStream().read(); if(data == -1 || data == 0x00 || data == '\n' || commReader.getInputStream().available() < 1) { break; } if(len == buffer.length) { processData(buffer); clearBuffer(); } buffer[len++] = (byte)data; } Before I would loop the while until data != -1. But that blocks on .close() and my program never gets to exit. Adding .available() < 1 as a break condition fixes it when I call .close() I am going to see if this is a linux kernel configuration issue or not cos it isn't so obvious and I hardly ever use .available() when reading streams. Love the project though :) -- George H george.dma at gmail.com On Tue, Feb 23, 2010 at 10:29 AM, Mariusz Dec wrote: > > > 2010/2/22 George H > > Hi, >> >> I am using RXTX v2.1-7. >> I use it to communicate with 2 serial receipt printers and 1 serial line >> display device. My program runs well using the RXTX library on Windows and >> Linux. >> But... when I installed Linux on another hardware the program does not >> exit properly. By this I mean that the java program seems to have exited >> (passed the System.exit(0)) code but the console still does not return to >> the bash shell. >> >> Thread in Noember 2009' - > > http://mailman.qbang.org/pipermail/rxtx/2009-November/5778408.html > > I have disocvered one technique which solved this problem in Linux Ubuntu > and Mac for RXTX pre2.2, but should helps in 2.1.7 as well. > > Regards > Mariusz > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 01:02:21 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 13:32:21 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> My serial port driver(apparently) does not support receive timeout.I registered an event listener for DATA_AVAILABLE. However, the control never seems to come out of the 'while' loop.Shouldn't the InputStream.read return a '-1' immediately if no data is available (this seems to be the default operation)? This was tried on a x86 Linux desktop using rxtx-2.1-7 I've added the snippet for clarity: /******************************************************************************************************************************************************************************/ mySerialPort.enableReceiveThreshold(2000);//Trying to set a time limit for read calls System.out.println(mySerialPort.isReceiveTimeoutEnabled()); // I get FALSE, so its not supported on hardware. mySerialPort.addEventListener(this); mySerialPort.notifyOnDataAvailable(true);//register a event with //my SerialEvent listener implementation: public void serialEvent(SerialPortEvent arg0) { int newData=0; switch(arg0.getEventType()){ case SerialPortEvent.DATA_AVAILABLE: while (newData != -1) { try { newData = is.read();//This should eventually return a -1 if no data is available within a timeout.PROBLEM!! System.out.println("Got a byte from port:"+newData); if (newData == -1) { break; } } catch (IOException ex) { System.err.println(ex); return; } } break; } return; } /******************************************************************************************************************************************************************************/ Thanks and regards, Ravi From michael.erskine at ketech.com Wed Feb 3 02:26:50 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 09:26:50 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From michael.erskine at ketech.com Wed Feb 3 05:03:30 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 12:03:30 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > Michael Erskine > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > > Your event handler should handle the event and return immediately so that its > controlling thread can handle other events. I recommend a single read in the > following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) > reads all available bytes up to the size of the buffer returning the number of > bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } After posting this I considered the glaring possibility of the rawbuf read buffer being too small to receive all the available bytes and perhaps skipping data: after all, I'm guessing that is why we see so many posts asking for help with blocking implementations of read event handlers looping on "while(bytes are available)". I've spent this morning writing an extensive multi-threaded unit test suite that includes tests with a tiny buffer compared to the amount of data available and found that no data was being skipped. I now want to know why! The SerialPortEvent.DATA_AVAILABLE event must be being fired again if there is more data available on the input stream. If that is the case then it should be heavily documented with good examples in the wiki to avoid the types of developer anguish we see so regularly. BTW: I'm not at liberty to post the JUnit tests as they use my company's unit test suite framework. Regards, Michael Erskine. From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 06:18:04 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 18:48:04 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Hello Michael, I tried out your suggestion but the problem is that the read(rawbuf) blocks until the entire length of the rawbuf array has been read (blocking). I cannot decide on a reasonable size of the array because it varies from 2 bytes to as much as 50 byes (i'm communicating with a modem,each response is of a different length), which is why i wanted to use non blocking calls. But on a side note, read(byte[]) in turn calls the read() in a loop.In the native C function, the read is supposed to return a -1 upon timeout.But my driver does not support timeout.The default timeout value is zero and the linux select call upon zero time out causes an infinite wait.What am i missing...... Thanks and regards, Ravi Date: Wed, 3 Feb 2010 09:26:50 +0000 From: Michael Erskine To: "rxtx at qbang.org" Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: Content-Type: text/plain; charset="us-ascii" > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From m.kirkland at comcast.net Wed Feb 3 06:46:03 2010 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 3 Feb 2010 05:46:03 -0800 Subject: [Rxtx] One port blocking another port In-Reply-To: References: Message-ID: <68768633814F4D7D86761D34F0764FE0@bengal.net> It turns out this is caused by having the RTS/CTS flow control turned on and me not providing a true on the RTS pin. Somehow it seems the port timing out on a read allows the write to proceed. This is not an issue for my application but I wonder if the write should not proceed until the RTS pin is true even if a read times out. mk -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Monday, January 25, 2010 7:48 PM To: Mike Kirkland Cc: rxtx at qbang.org Subject: Re: [Rxtx] One port blocking another port On Mon, 25 Jan 2010, Mike Kirkland wrote: > > Hi All, > > ? > > I have a program that reads from one com port and writes to another com > port. It also does the same thing in reverse (reads from the second com port > and writes to the first one. It basically ties two com ports together. > > ? > > One port is very chatty and has a consent stream of data. The other port has > very little data. > > ? > > Both ports use a 5000 ms (5 second) time out. > > ? > > The issue I am having is that is appears that the first port?s write to the > second port is blocked while the second port is waiting for input. The first > port?s write proceeds only after the second port has timed out. > > ? > > I suppose I could have something twisted around in my code but I was > wondering if this is a know issue? > Hi Kirk, I've not seen a report like this. Perhaps some simple reproduction code will reveal a problem on your end or help us identify a problem in rxtx. I think there are several users doing multiport communication. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Wed Feb 3 07:03:58 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:03:58 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Message-ID: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> 2010/2/3 Ravishankar N > Hello Michael, > [..] > But on a side note, read(byte[]) in turn calls the read() in a loop.In the > native C function, the read is supposed to return a -1 upon timeout.But my > driver > does not support timeout.The default timeout value is zero and the linux > select call upon zero time out causes an infinite wait.What am i > missing...... > > When I have tested RXTX between platforms, I have observed "hangup" inside JNI driver when no data in Linux, is normal thing. Solution was setting the timeout for RXTX when no data from JNI driver. Something like that: commPort.enableReceiveTimeout(10); And it works perfect.... The only difference is that I am NOT using events - I am using continous read in separate thread and if data is available, is parsed and transferred to application using exception. Regards Mariusz > Thanks and regards, > Ravi > > Date: Wed, 3 Feb 2010 09:26:50 +0000 > From: Michael Erskine > To: "rxtx at qbang.org" > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > Message-ID: > > > Content-Type: text/plain; charset="us-ascii" > > > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of > > Ravishankar N > > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > > > My serial port driver(apparently) does not support receive timeout.I > > registered an event listener for DATA_AVAILABLE. However, the control > never > > seems to come out of the 'while' loop.Shouldn't the > > InputStream.read return a '-1' immediately if no data is available (this > seems > > to be the default operation)? > > Your event handler should handle the event and return immediately so that > its controlling thread can handle other events. I recommend a single read in > the following manner: rawbuf is a byte[] of "reasonable" size and the > read(byte[]) reads all available bytes up to the size of the buffer > returning the number of bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } > > This style of reading has worked for me with RXTX on Linux and Windows XP > for a good few years now in railway industry communications systems. Any > timeouts (largely unnecessary in my applications) can be handled elsewhere, > usually at a higher layer. > > Regards, > Michael Erskine. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Feb 3 07:22:55 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 3 Feb 2010 09:22:55 -0500 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: I'm guessing that this is driver specific. I recently had to support a select()/poll() infrastructure for a linux serial DD, its certainly non trivial to support async IO, so I suspect the problem in this case has to do with missing poll infrastructure in the device driver. This also has to coupled with special open flags for the device (which is within the rxtx code) The key routines within a 2.6 kernel linux device driver are shown below (if you have access to it for your particular device) are indicated below (here is a snippet from my device driver c code that supports polling/select). User space code to test this shown below also, note that the device needs to be opened with the O_NONBLOCK option to support the select/poll api // device driver code ..... /* * File operations supported by this driver. */ static struct file_operations iop_fops = { .owner = THIS_MODULE, .check_flags= iop_check_flags, .ioctl = iop_ioctl, .open = iop_open, .poll = iop_poll, // SUPPORT FOR SELECT/POLL infrastructure .read = iop_read, .release = iop_release, .write = iop_write, }; /** * Select/poll/epoll infrastructure. * * @param file * @param wait * * @return */ static unsigned int iop_poll(struct file *filp, poll_table *wait) { struct iop_device *devp = (struct iop_device *)filp->private_data; // the poll_table wait arg is an opaque pointer poll_wait(filp, &devp->readq, wait); // return from poll indicating whether we have read/write data unsigned int mask = 0; if (kfifo_len(devp->rx_fifo)) { mask |= (POLLIN | POLLRDNORM); } // @JC We don't do select on write yet // if (kfifo_len(devp->tx_fifo)) { // mask |= (POLLOUT | POLLWRNORM); // } // Only print out while debugging // if (mask != 0) { // printk (KERN_INFO "%s: [%04x]\n", __FUNCTION__, mask); // } return mask; } /** * device driver blocking and non blocking read function. This * function reads the requested number of bytes from the read * kfifo blocking as required. * * @param filp * @param buf * @param count * @param f_pos * * @return */ static ssize_t iop_read(struct file *filp, char __user *buf, size_t count, loff_t * ppos) { // access appropriate device struct struct iop_device *devp = (struct iop_device *) filp->private_data; ssize_t retval; // support non blocking mode (default) by checking if the kfifo is empty first if ((kfifo_len(devp->rx_fifo)==0) && (filp->f_flags & O_NONBLOCK)) { return -EAGAIN; } // wait for rx_fifo to receive data via receive interrupts retval = wait_event_interruptible(devp->readq, kfifo_len(devp->rx_fifo) != 0); // check for some error condition if (retval) { printk (KERN_ERR "%s: wait_event_interruptible returned[%d]\n", __FUNCTION__, retval); return retval; } // copy max requested bytes from rx_fifo to device buffer // this may still leave bytes in the kfifo for a subsequent read // if we are reading in a loop retval = kfifo_get(devp->rx_fifo, devp->rxbuf, count); // printk (KERN_INFO "%s: [%d] byte(s)\n", __FUNCTION__, retval); if (copy_to_user(buf, devp->rxbuf, retval)) { printk (KERN_ERR "%s: problem copying rx_fifo data to user buffer\n", __FUNCTION__); return -EFAULT; } return retval; } // a selection of my user space code reading via select()/poll()..... // user space open code iop_fd = ::open( deviceName.data(), O_RDWR | O_NONBLOCK); while ((bytes_to_expect - bytes_read) > 0) { // must reinitialize these between select calls fd_set readfds; FD_ZERO( &readfds ); FD_SET( iop_fd, &readfds ); // 1s sec read polling timeout struct timeval timeout; timeout.tv_sec = 1; timeout.tv_usec = 0; int rc = select( FD_SETSIZE, &readfds, NULL, NULL, &timeout ); // read from file when descriptor // indicates data available without blocking if ((rc > 0) && FD_ISSET(iop_fd, &readfds)) { // read into the appropriate offset within the rx_buf int temp = read(iop_fd, rx_buf + bytes_read, bytes_to_expect - bytes_read); if (!temp) { printf("EOF detected with %d bytes expected\n", bytes_to_expect - bytes_read); } else { bytes_read += temp; } } else if (rc < 0){ printf("%s: select on [%s], bytes_read[%d], errno=%d\n", __FUNCTION__, thread_args->device, bytes_read, errno); } else { printf("%s: select on [%s], bytes_read[%d], timeout\n", __FUNCTION__, thread_args->device, bytes_read); } } On Wed, Feb 3, 2010 at 9:03 AM, Mariusz Dec wrote: > > > 2010/2/3 Ravishankar N > >> Hello Michael, >> [..] >> >> But on a side note, read(byte[]) in turn calls the read() in a loop.In the >> native C function, the read is supposed to return a -1 upon timeout.But my >> driver >> does not support timeout.The default timeout value is zero and the linux >> select call upon zero time out causes an infinite wait.What am i >> missing...... >> >> > When I have tested RXTX between platforms, I have observed "hangup" inside > JNI driver when no data in Linux, is normal thing. > > Solution was setting the timeout for RXTX when no data from JNI driver. > > Something like that: > > commPort.enableReceiveTimeout(10); > > And it works perfect.... > > The only difference is that I am NOT using events - I am using continous > read in separate thread and if data is available, is parsed and transferred > to application using exception. > > Regards > Mariusz > > > >> Thanks and regards, >> Ravi >> >> Date: Wed, 3 Feb 2010 09:26:50 +0000 >> From: Michael Erskine >> To: "rxtx at qbang.org" >> Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? >> Message-ID: >> >> >> Content-Type: text/plain; charset="us-ascii" >> >> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >> Of >> > Ravishankar N >> > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? >> > >> > My serial port driver(apparently) does not support receive timeout.I >> > registered an event listener for DATA_AVAILABLE. However, the control >> never >> > seems to come out of the 'while' loop.Shouldn't the >> > InputStream.read return a '-1' immediately if no data is available (this >> seems >> > to be the default operation)? >> >> Your event handler should handle the event and return immediately so that >> its controlling thread can handle other events. I recommend a single read in >> the following manner: rawbuf is a byte[] of "reasonable" size and the >> read(byte[]) reads all available bytes up to the size of the buffer >> returning the number of bytes actually read... >> >> case SerialPortEvent.DATA_AVAILABLE: >> try { >> int i = is.read(rawbuf); >> if (i == -1) { >> << process EOF condition - should never happen >> >> return; >> } >> << process bytes (rawbuf, i); >> >> return; >> } catch (IOException e) { >> << promptly deal with exception >> >> return; >> } >> >> This style of reading has worked for me with RXTX on Linux and Windows XP >> for a good few years now in railway industry communications systems. Any >> timeouts (largely unnecessary in my applications) can be handled elsewhere, >> usually at a higher layer. >> >> Regards, >> Michael Erskine. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Feb 3 07:33:27 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:33:27 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: <73a89f361002030633j682610afia48dc7accd8e049b@mail.gmail.com> 2010/2/3 John Coffey > I'm guessing that this is driver specific. I recently had to support a > select()/poll() infrastructure for a linux serial DD, its certainly non > trivial to support async IO, so I suspect the problem in this case has to do > with missing poll infrastructure in the device driver. This also has to > coupled with special open flags for the device (which is within the rxtx > code) > > Yes, you are right, it may be driver specific, but in my case I haven't changed blocking JNI driver. I have added ONLY one call to RXTX method mentioned in my previous post and blocking (as seen as from Java app) gone out... Maybe this is not elegant, but works without problem in my app. I am using only FTDI chips and their drivers from couple of years and maybe this is the kind of the way to have no many problems with serial as well? Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From andyrxtx at g0poy.co.uk Wed Feb 3 11:09:04 2010 From: andyrxtx at g0poy.co.uk (andyrxtx at g0poy.co.uk) Date: Wed, 3 Feb 2010 18:09:04 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes Message-ID: <20100203180904.164f24dd@workstation.site> ?Hello RXTX group, I have just joined this group, and this is my first posting. I wanted to pass on some information regarding rxtx, so apologies if this has been brought up before. I have searched back through the archives but nothing specific came up. I am not a Java programmer, and I only came across rxtx a few days ago. I use a piece of test equipment called a miniVNA http://www.miniradiosolutions.com/ This is a serial USB controlled instrument, and it has control software available for MS windows, and a very old and now non-working Linux application. A few days ago Dietmar, DL2SBA released a Java application to control the miniVNA, obviously this application makes use of rxtx. The program worked fine on Windows, so I set about installing it onto Linux. I use SUSE11.1 After a few false starts, I got the system running fairly easily, sorting out the file locking by adding the uucp group to the users account as suggested (I used the 2.2pre binary files) I then passed the install instructions onto another miniVNA user, who also uses SUSE, but he ran into problems. To cut a long story short, he was also having file lock problems, but the uucp fix did not work. Digging into his system I found that there have been some changes in SUSE 11.2. tty ports are now assigned to the dialout group rather than uucp. A hint in the rxtx INSTALL file, suggested that var/lock needs to be checked, so: SUSE 11.1, var/lock is root:uucp SUSE 11.2 var/lock is root:root A search on Google brought up several comments regarding this, and also a bugzilla entry. https://bugzilla.novell.com/show_bug.cgi?id=552095 However from reading the various posts, some of which are in the bugzilla entry, it appears that many distros may be, or have changed to this configuration, and this will undoubtedly break several things, rxtx included. I solved my fellow SUSE users problem by compiling the rxtx libs with the no lock file option during configure, and that solved his problem. As this issue will probably take some time to get resolved across all the various Linux distros, it might be worth considering changing the default on the Linux build of rxtx not to use lockfiles, or provide the two versions of the lib in the binary archive. Thanks for your indulgence Andy From damorales at gmail.com Wed Feb 3 11:33:23 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 15:33:23 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203180904.164f24dd@workstation.site> References: <20100203180904.164f24dd@workstation.site> Message-ID: Hi I had the same problem in Mandriva 2010 and yes, adding the user to the uucp group did not work as it used to be in earlier versions of linux distros, causing RXTX to not work as non root user. The problem appears because the existense of UDEV, now you MUST add a RULE so the group (uucp or whatever) have access (Read, Write, Execute) to the Serial Port. To solve the problem, without needing to recompile RXTX, you must add a rule to grant permissions (0666) to the group for the device or port (tty*, ttyUSB*, etc). I do not remember now what is the line i added but when i come back home i will give it to you (i am at work now). Greetings ! 2010/2/3 > Hello RXTX group, > > I have just joined this group, and this is my first posting. > I wanted to pass on some information regarding rxtx, so apologies if > this has been brought up before. I have searched back through the > archives but nothing specific came up. > > I am not a Java programmer, and I only came across rxtx a few days ago. > > I use a piece of test equipment called a miniVNA > http://www.miniradiosolutions.com/ > > This is a serial USB controlled instrument, and it has control software > available for MS windows, and a very old and now non-working Linux > application. > > A few days ago Dietmar, DL2SBA released a Java application to control the > miniVNA, obviously this application makes use of rxtx. > > The program worked fine on Windows, so I set about installing it onto > Linux. I use SUSE11.1 After a few false starts, I got the system running > fairly easily, sorting out the file locking by adding the uucp group to > the users account as suggested (I used the 2.2pre binary files) I then > passed the install instructions onto another miniVNA user, who also uses > SUSE, but he ran into problems. To cut a long story short, he was > also having file lock problems, but the uucp fix did not work. Digging > into his system I found that there have been some changes in SUSE 11.2. > > tty ports are now assigned to the dialout group rather than uucp. > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > checked, so: > > SUSE 11.1, var/lock is root:uucp > SUSE 11.2 var/lock is root:root > > A search on Google brought up several comments regarding this, and also > a bugzilla entry. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > However from reading the various posts, some of which are in the bugzilla > entry, it appears that many distros may be, or have changed to this > configuration, and this will undoubtedly break several things, rxtx > included. > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > no lock file option during configure, and that solved his problem. > > As this issue will probably take some time to get resolved across all the > various Linux distros, it might be worth considering changing the default > on the Linux build of rxtx not to use lockfiles, or provide the two > versions of the lib in the binary archive. > > Thanks for your indulgence > > Andy > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Wed Feb 3 12:07:02 2010 From: andy at g0poy.com (Andy Eskelson) Date: Wed, 3 Feb 2010 19:07:02 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> Message-ID: <20100203190702.1b0e7015@workstation.site> Thanks Daniel, I am aware of the permissions problem, I have had a udev rules to solve this for other programs for some time. . I don't think that this is the same problem. as far as I can understand things, the lock files are written in var/lock. Previously var/lock and dev/tty-whatever were the same group. Now with var/lock owned by and with a group of root:root anything other than root cannot create a lock file. Even minicom is broken by this change. This change is going to have quite a few knock-on effects I think. Andy On Wed, 3 Feb 2010 15:33:23 -0300 Daniel Morales Salas wrote: > Hi > > I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > group did not work as it used to be in earlier versions of linux distros, > causing RXTX to not work as non root user. > > The problem appears because the existense of UDEV, now you MUST add a RULE > so the group (uucp or whatever) have access (Read, Write, Execute) to the > Serial Port. > > To solve the problem, without needing to recompile RXTX, you must add a rule > to grant permissions (0666) to the group for the device or port (tty*, > ttyUSB*, etc). I do not remember now what is the line i added but when i > come back home i will give it to you (i am at work now). > > Greetings ! > > 2010/2/3 > > > Hello RXTX group, > > > > I have just joined this group, and this is my first posting. > > I wanted to pass on some information regarding rxtx, so apologies if > > this has been brought up before. I have searched back through the > > archives but nothing specific came up. > > > > I am not a Java programmer, and I only came across rxtx a few days ago. > > > > I use a piece of test equipment called a miniVNA > > http://www.miniradiosolutions.com/ > > > > This is a serial USB controlled instrument, and it has control software > > available for MS windows, and a very old and now non-working Linux > > application. > > > > A few days ago Dietmar, DL2SBA released a Java application to control the > > miniVNA, obviously this application makes use of rxtx. > > > > The program worked fine on Windows, so I set about installing it onto > > Linux. I use SUSE11.1 After a few false starts, I got the system running > > fairly easily, sorting out the file locking by adding the uucp group to > > the users account as suggested (I used the 2.2pre binary files) I then > > passed the install instructions onto another miniVNA user, who also uses > > SUSE, but he ran into problems. To cut a long story short, he was > > also having file lock problems, but the uucp fix did not work. Digging > > into his system I found that there have been some changes in SUSE 11.2. > > > > tty ports are now assigned to the dialout group rather than uucp. > > > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > checked, so: > > > > SUSE 11.1, var/lock is root:uucp > > SUSE 11.2 var/lock is root:root > > > > A search on Google brought up several comments regarding this, and also > > a bugzilla entry. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > However from reading the various posts, some of which are in the bugzilla > > entry, it appears that many distros may be, or have changed to this > > configuration, and this will undoubtedly break several things, rxtx > > included. > > > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > > no lock file option during configure, and that solved his problem. > > > > As this issue will probably take some time to get resolved across all the > > various Linux distros, it might be worth considering changing the default > > on the Linux build of rxtx not to use lockfiles, or provide the two > > versions of the lib in the binary archive. > > > > Thanks for your indulgence > > > > Andy > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From thisdyingdream at gmail.com Wed Feb 3 12:32:35 2010 From: thisdyingdream at gmail.com (Steven Harms) Date: Wed, 3 Feb 2010 14:32:35 -0500 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203190702.1b0e7015@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: This is currently a bug in OpenSUSE that affects more than just rxtx, and is a result of unified udev rules. You can work around this by making udev change the group back to uucp until something more happens. https://bugzilla.novell.com/show_bug.cgi?id=552095 Thanks, Steve On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > Thanks Daniel, > > I am aware of the permissions problem, I have had a udev rules to solve > this for other programs for some time. > . > I don't think that this is the same problem. as far as I can understand > things, the lock files are written in var/lock. Previously var/lock and > dev/tty-whatever were the same group. Now with var/lock owned by and with > a group of root:root anything other than root cannot create a lock > file. Even minicom is broken by this change. > > This change is going to have quite a few knock-on effects I think. > > > Andy > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > Daniel Morales Salas wrote: > >> Hi >> >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp >> group did not work as it used to be in earlier versions of linux distros, >> causing RXTX to not work as non root user. >> >> The problem appears because the existense of UDEV, now you MUST add a RULE >> so the group (uucp or whatever) have access (Read, Write, Execute) to the >> Serial Port. >> >> To solve the problem, without needing to recompile RXTX, you must add a rule >> to grant permissions (0666) to the group for the device or port (tty*, >> ttyUSB*, etc). I do not remember now what is the line i added but when i >> come back home i will give it to you (i am at work now). >> >> Greetings ! >> >> 2010/2/3 >> >> > Hello RXTX group, >> > >> > I have just joined this group, and this is my first posting. >> > I wanted to pass on ?some information regarding rxtx, so apologies if >> > this has been brought up before. I have searched back through the >> > archives but nothing specific came up. >> > >> > I am not a Java programmer, and I only came across rxtx a few days ago. >> > >> > I use a piece of test equipment called a miniVNA >> > http://www.miniradiosolutions.com/ >> > >> > This is a serial USB controlled instrument, and it has control software >> > available for MS windows, and a very old and now non-working Linux >> > application. >> > >> > A few days ago Dietmar, DL2SBA released a Java application to control the >> > miniVNA, obviously this application makes use of rxtx. >> > >> > The program worked fine on Windows, so I set about installing it onto >> > Linux. I use SUSE11.1 After a few false starts, I got the system running >> > fairly easily, sorting out the file locking by adding the uucp group to >> > the users account as suggested (I used the 2.2pre binary files) I then >> > passed the install instructions onto another miniVNA user, who also uses >> > SUSE, but he ran into problems. To cut a long story short, he was >> > also having file lock problems, but the uucp fix did not work. Digging >> > into his system I found that there have been some changes in SUSE 11.2. >> > >> > tty ports are now assigned to the dialout group rather than uucp. >> > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be >> > checked, so: >> > >> > SUSE 11.1, var/lock is root:uucp >> > SUSE 11.2 var/lock is root:root >> > >> > A search on Google brought up several comments regarding this, and also >> > a ?bugzilla entry. >> > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 >> > >> > However from reading the various posts, some of which are in the bugzilla >> > entry, it appears that many distros may be, or have changed to this >> > configuration, and this will undoubtedly break several things, rxtx >> > included. >> > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the >> > no lock file option during configure, and that solved his problem. >> > >> > As this issue will probably take some time to get resolved across all the >> > various Linux distros, it might be worth considering changing the default >> > on the Linux build of rxtx not to use lockfiles, or provide the two >> > versions of the lib in the binary archive. >> > >> > Thanks for your indulgence >> > >> > Andy >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> >> >> >> -- >> Atte: >> Daniel Dario Morales Salas >> Ingeniero Civil en Computaci?n e Inform?tica >> Tel?fono: 02 684 3417 >> Celular: 09 643 1802 >> Santiago, Chile > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 WWW: http://www.sharms.org/blog From andy at g0poy.com Wed Feb 3 17:58:29 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 00:58:29 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: <20100204005829.7dc944e1@workstation.site> Thanks Steve, changing the serial ports back the uucp is not a big problem. I have a udev rule that can be easily modified already. However I cannot see any way of dealing with the var/lock problem apart from making it writable to all. Any thoughts? Andy On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms wrote: > This is currently a bug in OpenSUSE that affects more than just rxtx, > and is a result of unified udev rules. You can work around this by > making udev change the group back to uucp until something more > happens. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > Thanks, > > Steve > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > Thanks Daniel, > > > > I am aware of the permissions problem, I have had a udev rules to solve > > this for other programs for some time. > > . > > I don't think that this is the same problem. as far as I can understand > > things, the lock files are written in var/lock. Previously var/lock and > > dev/tty-whatever were the same group. Now with var/lock owned by and with > > a group of root:root anything other than root cannot create a lock > > file. Even minicom is broken by this change. > > > > This change is going to have quite a few knock-on effects I think. > > > > > > Andy > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > Daniel Morales Salas wrote: > > > >> Hi > >> > >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > >> group did not work as it used to be in earlier versions of linux distros, > >> causing RXTX to not work as non root user. > >> > >> The problem appears because the existense of UDEV, now you MUST add a RULE > >> so the group (uucp or whatever) have access (Read, Write, Execute) to the > >> Serial Port. > >> > >> To solve the problem, without needing to recompile RXTX, you must add a rule > >> to grant permissions (0666) to the group for the device or port (tty*, > >> ttyUSB*, etc). I do not remember now what is the line i added but when i > >> come back home i will give it to you (i am at work now). > >> > >> Greetings ! > >> > >> 2010/2/3 > >> > >> > Hello RXTX group, > >> > > >> > I have just joined this group, and this is my first posting. > >> > I wanted to pass on ?some information regarding rxtx, so apologies if > >> > this has been brought up before. I have searched back through the > >> > archives but nothing specific came up. > >> > > >> > I am not a Java programmer, and I only came across rxtx a few days ago. > >> > > >> > I use a piece of test equipment called a miniVNA > >> > http://www.miniradiosolutions.com/ > >> > > >> > This is a serial USB controlled instrument, and it has control software > >> > available for MS windows, and a very old and now non-working Linux > >> > application. > >> > > >> > A few days ago Dietmar, DL2SBA released a Java application to control the > >> > miniVNA, obviously this application makes use of rxtx. > >> > > >> > The program worked fine on Windows, so I set about installing it onto > >> > Linux. I use SUSE11.1 After a few false starts, I got the system running > >> > fairly easily, sorting out the file locking by adding the uucp group to > >> > the users account as suggested (I used the 2.2pre binary files) I then > >> > passed the install instructions onto another miniVNA user, who also uses > >> > SUSE, but he ran into problems. To cut a long story short, he was > >> > also having file lock problems, but the uucp fix did not work. Digging > >> > into his system I found that there have been some changes in SUSE 11.2. > >> > > >> > tty ports are now assigned to the dialout group rather than uucp. > >> > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > >> > checked, so: > >> > > >> > SUSE 11.1, var/lock is root:uucp > >> > SUSE 11.2 var/lock is root:root > >> > > >> > A search on Google brought up several comments regarding this, and also > >> > a ?bugzilla entry. > >> > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > >> > > >> > However from reading the various posts, some of which are in the bugzilla > >> > entry, it appears that many distros may be, or have changed to this > >> > configuration, and this will undoubtedly break several things, rxtx > >> > included. > >> > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the > >> > no lock file option during configure, and that solved his problem. > >> > > >> > As this issue will probably take some time to get resolved across all the > >> > various Linux distros, it might be worth considering changing the default > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > >> > versions of the lib in the binary archive. > >> > > >> > Thanks for your indulgence > >> > > >> > Andy > >> > > >> > _______________________________________________ > >> > Rxtx mailing list > >> > Rxtx at qbang.org > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > >> > >> > >> > >> -- > >> Atte: > >> Daniel Dario Morales Salas > >> Ingeniero Civil en Computaci?n e Inform?tica > >> Tel?fono: 02 684 3417 > >> Celular: 09 643 1802 > >> Santiago, Chile > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > WWW: http://www.sharms.org/blog From damorales at gmail.com Wed Feb 3 18:26:38 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 22:26:38 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100204005829.7dc944e1@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: Hello I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva 2010 this is what i get: drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ and i don't have ANY problem with lock files and RXTX in my java software. All i had to do was add this rule to udev: # serial KERNEL=="tty*", GROUP="uucp", MODE="0666" and that was all. Of course my user (metalklesk) is part of uucp group. I did not make /var/lock writable to all users. Greetings ! 2010/2/3 Andy Eskelson > Thanks Steve, > > changing the serial ports back the uucp is not a big problem. I have a > udev rule that can be easily modified already. However I cannot see any > way of dealing with the var/lock problem apart from making it writable to > all. Any thoughts? > > Andy > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > wrote: > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > and is a result of unified udev rules. You can work around this by > > making udev change the group back to uucp until something more > > happens. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > Thanks, > > > > Steve > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > Thanks Daniel, > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > this for other programs for some time. > > > . > > > I don't think that this is the same problem. as far as I can understand > > > things, the lock files are written in var/lock. Previously var/lock and > > > dev/tty-whatever were the same group. Now with var/lock owned by and > with > > > a group of root:root anything other than root cannot create a lock > > > file. Even minicom is broken by this change. > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > Daniel Morales Salas wrote: > > > > > >> Hi > > >> > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > the uucp > > >> group did not work as it used to be in earlier versions of linux > distros, > > >> causing RXTX to not work as non root user. > > >> > > >> The problem appears because the existense of UDEV, now you MUST add a > RULE > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > the > > >> Serial Port. > > >> > > >> To solve the problem, without needing to recompile RXTX, you must add > a rule > > >> to grant permissions (0666) to the group for the device or port (tty*, > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > i > > >> come back home i will give it to you (i am at work now). > > >> > > >> Greetings ! > > >> > > >> 2010/2/3 > > >> > > >> > Hello RXTX group, > > >> > > > >> > I have just joined this group, and this is my first posting. > > >> > I wanted to pass on some information regarding rxtx, so apologies > if > > >> > this has been brought up before. I have searched back through the > > >> > archives but nothing specific came up. > > >> > > > >> > I am not a Java programmer, and I only came across rxtx a few days > ago. > > >> > > > >> > I use a piece of test equipment called a miniVNA > > >> > http://www.miniradiosolutions.com/ > > >> > > > >> > This is a serial USB controlled instrument, and it has control > software > > >> > available for MS windows, and a very old and now non-working Linux > > >> > application. > > >> > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > control the > > >> > miniVNA, obviously this application makes use of rxtx. > > >> > > > >> > The program worked fine on Windows, so I set about installing it > onto > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > running > > >> > fairly easily, sorting out the file locking by adding the uucp group > to > > >> > the users account as suggested (I used the 2.2pre binary files) I > then > > >> > passed the install instructions onto another miniVNA user, who also > uses > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > >> > also having file lock problems, but the uucp fix did not work. > Digging > > >> > into his system I found that there have been some changes in SUSE > 11.2. > > >> > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > >> > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > >> > checked, so: > > >> > > > >> > SUSE 11.1, var/lock is root:uucp > > >> > SUSE 11.2 var/lock is root:root > > >> > > > >> > A search on Google brought up several comments regarding this, and > also > > >> > a bugzilla entry. > > >> > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > >> > > > >> > However from reading the various posts, some of which are in the > bugzilla > > >> > entry, it appears that many distros may be, or have changed to this > > >> > configuration, and this will undoubtedly break several things, rxtx > > >> > included. > > >> > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > with the > > >> > no lock file option during configure, and that solved his problem. > > >> > > > >> > As this issue will probably take some time to get resolved across > all the > > >> > various Linux distros, it might be worth considering changing the > default > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > >> > versions of the lib in the binary archive. > > >> > > > >> > Thanks for your indulgence > > >> > > > >> > Andy > > >> > > > >> > _______________________________________________ > > >> > Rxtx mailing list > > >> > Rxtx at qbang.org > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > >> > > > >> > > >> > > >> > > >> -- > > >> Atte: > > >> Daniel Dario Morales Salas > > >> Ingeniero Civil en Computaci?n e Inform?tica > > >> Tel?fono: 02 684 3417 > > >> Celular: 09 643 1802 > > >> Santiago, Chile > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at qbang.org > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > -- > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > WWW: http://www.sharms.org/blog > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Thu Feb 4 05:31:46 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 12:31:46 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: <20100204123146.6cffeb67@workstation.site> Thank's for the confirmation. Something odd is going on somewhere in SUSE 11.2. I'll have to build up a local SUSE11.2 system to see if I can nail down exactly what is going on. Something is blocking the lockfiles in var/lock. The net is nice, but it's a bit difficult trying to work out what is going on what the machine in question is in Germany and I'm in the UK :-) Andy On Wed, 3 Feb 2010 22:26:38 -0300 Daniel Morales Salas wrote: > Hello > > I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva > 2010 this is what i get: > > drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ > > and i don't have ANY problem with lock files and RXTX in my java software. > All i had to do was add this rule to udev: > > # serial > KERNEL=="tty*", GROUP="uucp", MODE="0666" > > and that was all. Of course my user (metalklesk) is part of uucp group. > I did not make /var/lock writable to all users. > > Greetings ! > > 2010/2/3 Andy Eskelson > > > Thanks Steve, > > > > changing the serial ports back the uucp is not a big problem. I have a > > udev rule that can be easily modified already. However I cannot see any > > way of dealing with the var/lock problem apart from making it writable to > > all. Any thoughts? > > > > Andy > > > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > > wrote: > > > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > > and is a result of unified udev rules. You can work around this by > > > making udev change the group back to uucp until something more > > > happens. > > > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > > > Thanks, > > > > > > Steve > > > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > > Thanks Daniel, > > > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > > this for other programs for some time. > > > > . > > > > I don't think that this is the same problem. as far as I can understand > > > > things, the lock files are written in var/lock. Previously var/lock and > > > > dev/tty-whatever were the same group. Now with var/lock owned by and > > with > > > > a group of root:root anything other than root cannot create a lock > > > > file. Even minicom is broken by this change. > > > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > > Daniel Morales Salas wrote: > > > > > > > >> Hi > > > >> > > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > > the uucp > > > >> group did not work as it used to be in earlier versions of linux > > distros, > > > >> causing RXTX to not work as non root user. > > > >> > > > >> The problem appears because the existense of UDEV, now you MUST add a > > RULE > > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > > the > > > >> Serial Port. > > > >> > > > >> To solve the problem, without needing to recompile RXTX, you must add > > a rule > > > >> to grant permissions (0666) to the group for the device or port (tty*, > > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > > i > > > >> come back home i will give it to you (i am at work now). > > > >> > > > >> Greetings ! > > > >> > > > >> 2010/2/3 > > > >> > > > >> > Hello RXTX group, > > > >> > > > > >> > I have just joined this group, and this is my first posting. > > > >> > I wanted to pass on some information regarding rxtx, so apologies > > if > > > >> > this has been brought up before. I have searched back through the > > > >> > archives but nothing specific came up. > > > >> > > > > >> > I am not a Java programmer, and I only came across rxtx a few days > > ago. > > > >> > > > > >> > I use a piece of test equipment called a miniVNA > > > >> > http://www.miniradiosolutions.com/ > > > >> > > > > >> > This is a serial USB controlled instrument, and it has control > > software > > > >> > available for MS windows, and a very old and now non-working Linux > > > >> > application. > > > >> > > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > > control the > > > >> > miniVNA, obviously this application makes use of rxtx. > > > >> > > > > >> > The program worked fine on Windows, so I set about installing it > > onto > > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > > running > > > >> > fairly easily, sorting out the file locking by adding the uucp group > > to > > > >> > the users account as suggested (I used the 2.2pre binary files) I > > then > > > >> > passed the install instructions onto another miniVNA user, who also > > uses > > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > > >> > also having file lock problems, but the uucp fix did not work. > > Digging > > > >> > into his system I found that there have been some changes in SUSE > > 11.2. > > > >> > > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > > >> > > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > > >> > checked, so: > > > >> > > > > >> > SUSE 11.1, var/lock is root:uucp > > > >> > SUSE 11.2 var/lock is root:root > > > >> > > > > >> > A search on Google brought up several comments regarding this, and > > also > > > >> > a bugzilla entry. > > > >> > > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > >> > > > > >> > However from reading the various posts, some of which are in the > > bugzilla > > > >> > entry, it appears that many distros may be, or have changed to this > > > >> > configuration, and this will undoubtedly break several things, rxtx > > > >> > included. > > > >> > > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > > with the > > > >> > no lock file option during configure, and that solved his problem. > > > >> > > > > >> > As this issue will probably take some time to get resolved across > > all the > > > >> > various Linux distros, it might be worth considering changing the > > default > > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > > >> > versions of the lib in the binary archive. > > > >> > > > > >> > Thanks for your indulgence > > > >> > > > > >> > Andy > > > >> > > > > >> > _______________________________________________ > > > >> > Rxtx mailing list > > > >> > Rxtx at qbang.org > > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > > >> > > > > >> > > > >> > > > >> > > > >> -- > > > >> Atte: > > > >> Daniel Dario Morales Salas > > > >> Ingeniero Civil en Computaci?n e Inform?tica > > > >> Tel?fono: 02 684 3417 > > > >> Celular: 09 643 1802 > > > >> Santiago, Chile > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at qbang.org > > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > > > -- > > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > > > WWW: http://www.sharms.org/blog > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From Bob_Jacobsen at lbl.gov Thu Feb 4 09:26:49 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Thu, 4 Feb 2010 08:26:49 -0800 Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 Message-ID: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're using RXTX-2.2pre2, although it emits the known message about "Version mismatch". WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 After the usual messing around, we've got it working on 11 Windows versions, multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ have things working rarely say so, so I don't know whether anybody has gotten it to work on 10.4 or not. The problem encountered is this: dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib dyld: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib followed by the JVM crashing hard. I've got those dump files if that would help. Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If so, is there a patch I can get and build? Thanks Bob -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From tjarvi at qbang.org Thu Feb 4 14:22:21 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 4 Feb 2010 14:22:21 -0700 (MST) Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 In-Reply-To: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> References: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> Message-ID: On Thu, 4 Feb 2010, Bob Jacobsen wrote: > We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're > using RXTX-2.2pre2, although it emits the known message about "Version > mismatch". > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > > After the usual messing around, we've got it working on 11 Windows versions, > multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with > a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ > have things working rarely say so, so I don't know whether anybody has gotten > it to work on 10.4 or not. > > The problem encountered is this: > > dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > dyld: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > followed by the JVM crashing hard. I've got those dump files if that would > help. > > Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If > so, is there a patch I can get and build? > Hi Bob, I talked to a coworker about the problem you ran into. It appears that it is possible to target 'older' Mac systems through makefile configuration changes. "Configuring a Makefile-Based Project If you have a makefile-based project, you can also take advantage of SDK-based development, by adding the appropriate options to your compile and link commands. Using SDKs in makefile-based projects requires GCC 4.0 or later. To choose an SDK, you use the -isysroot option with the compiler and the -syslibroot option with the linker. Both options require that you specify the full path to the desired SDK directory. To set the Deployment OS version in a makefile, use a makefile variable of the form: ENVP= MACOSX_DEPLOYMENT_TARGET=10.4. To use this variable in your makefile, include it in front of your compile and link commands." http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html Or build on the oldest system you want to support. -- Trent Jarvi tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Thu Feb 4 14:56:19 2010 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Thu, 4 Feb 2010 14:56:19 -0700 Subject: [Rxtx] RXTX on 64 Bit Redhat In-Reply-To: References: <4ec9eab61001281448g3dd84910r867619948a4e0d7a@mail.gmail.com> Message-ID: Trent -- Finally fixed all my build related issues. I ran into another issue. On one of my machines my JDK is returning multiple folders for the "java.ext.dirs" (java.ext.dirs -> /opt/jdk1.6.0_17/jre/lib/ext:/usr/java/packages/lib/ext) system property. As a result my JVM wasn't able to detect the gnu.io.rxtx.properties. I am attaching a patch for RXTXCommDriver.java file to check for multiple locations. Also i have to assign permission 660 to all my dev ports to be located by RXTX. Pawan ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 5:12 PM To: Trent Jarvi Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Here is the error i get when i build the src from release-2-1-7 -bash-3.2$ make ( \ \ cd i686-pc-linux-gnu; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/ jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I/opt/jav a1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec - c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialImp.lo;\ if [ "Serial" = "Serial" ]; then \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I /opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_tim espec -c /home/jb_stg/rxtx/rxtx-devel/./src/fuserImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ else \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo; \ fi; \ ) gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/inclu de -I/opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need _timespec -c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -fPIC -DPIC -o /hom e/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/.libs/SerialImp.o /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:25:29: error: gnu_io_RXTXPort.h: No such file or directory In file included from /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:113: /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:91: error: expected specifier-qua lifier-list before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'jobject' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:408: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:409: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:410: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:411: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:415: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:416: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:417: error: expected '=', ',', '; ', 'asm' or '__attribute__' before 'is_interrupted' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:418: error: expected declaration specifiers or '...' before 'jint' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:424: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:441: error: expected ')' before ' *' token ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 4:57 PM To: Santosh Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Santosh -- Thank you. That fixed the issue. All -- What CVS branch or release should i use to get the latest RXTX src code. Pawan ________________________________ From: Santosh [mailto:santosh.ry at gmail.com] Sent: Thursday, January 28, 2010 3:49 PM To: Kharbanda, Pawan Cc: Trent Jarvi; rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat error "./configure: /bin/sh^M: bad interpreter: No such file or directory". I think you need to run dos2unix on script files before compiling. Thanks, Santosh On Thu, Jan 28, 2010 at 5:33 PM, Kharbanda, Pawan > wrote: Trent -- We are upgrading our exisiting OS and JDK on a project that rely heavily on RXTX api's. We are now using JDK1.6 32 bit (build 1.6.0_17-b04) and RedHat 5 on a 64 bit machine. Linux tocrhstg02.dot.state.co.us 2.6.18-164.6.1.el5 #1 SMP Tue Oct 27 11:30:06 EDT 2009 i686 i686 i386 GNU/Linux Red Hat Enterprise Linux Server release 5.4 (Tikanga) I tried to run version 2.1.7 r2 on it but not able to see any of my Digi ports I was able to access only /dev/ttyS0 (physical ports). Not sure if the problem is with the Digi driver or RXTX. I tried to open a Digi port with minicom and it worked fine. I also tried to get latest from CVS (rxtx-devel) and when I do "configure" I see this error "./configure: /bin/sh^M: bad interpreter: No such file or directory". Can someone please help me with this? Thanks for the help. Pawan _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch.txt URL: From juan.vicente.l.g at gmail.com Sat Feb 13 04:44:17 2010 From: juan.vicente.l.g at gmail.com (Juan Vicente Lopez Gutierrez) Date: Sat, 13 Feb 2010 12:44:17 +0100 Subject: [Rxtx] RXTX in macmini OSX 10.5 Message-ID: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> Hello. My name is Juanvi and I'm from Spain. I tried to launch a software created by me in the library CXR java to send information through the serial port and I can not make it work. In windows if I've done but not mac. I have a mac mini with OSX 10.5 and have read in the list of web mail that you CXR if you have managed to make it work on that operating system. I need you help me please. Do I make the mistake that shows me java: run: Stable Library =============================== Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 gnu.io.PortInUseException: Unknow Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:26) at TwoWatSerialComm.main(TwoWaySerialComm.java:106) Experimental: JNI_OnLoad called. GENERACION CORRECTA (total time: 0 seconds) I do not have permission to access the serial port, do not know. Os agradeceria much to sit down. A greeting and thanks. Pardon my English. Juanvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From juan.vicente.l.g at gmail.com Sat Feb 13 14:39:41 2010 From: juan.vicente.l.g at gmail.com (Juan Vicente Lopez Gutierrez) Date: Sat, 13 Feb 2010 22:39:41 +0100 Subject: [Rxtx] Fwd: RXTX in macmini OSX 10.5 In-Reply-To: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> References: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> Message-ID: <29405e5c1002131339m2059d169sdc8549ed9706a1af@mail.gmail.com> ---------- Forwarded message ---------- From: Juan Vicente Lopez Gutierrez Date: 2010/2/13 Subject: RXTX in macmini OSX 10.5 To: rxtx at qbang.org Hello. My name is Juanvi and I'm from Spain. I tried to launch a software created by me in the library CXR java to send information through the serial port and I can not make it work. In windows if I've done but not mac. I have a mac mini with OSX 10.5 and have read in the list of web mail that you CXR if you have managed to make it work on that operating system. I need you help me please. Do I make the mistake that shows me java: run: Stable Library =============================== Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 gnu.io.PortInUseException: Unknow Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:26) at TwoWatSerialComm.main(TwoWaySerialComm.java:106) Experimental: JNI_OnLoad called. GENERACION CORRECTA (total time: 0 seconds) I do not have permission to access the serial port, do not know. Os agradeceria much to sit down. A greeting and thanks. Pardon my English. Juanvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Mon Feb 22 04:35:48 2010 From: george.dma at gmail.com (George H) Date: Mon, 22 Feb 2010 13:35:48 +0200 Subject: [Rxtx] Lingering rxtx process Message-ID: Hi, I am using RXTX v2.1-7. I use it to communicate with 2 serial receipt printers and 1 serial line display device. My program runs well using the RXTX library on Windows and Linux. But... when I installed Linux on another hardware the program does not exit properly. By this I mean that the java program seems to have exited (passed the System.exit(0)) code but the console still does not return to the bash shell. I have to CTRL+C each time to kill the program. And on each restart RXTX has to remove stale LCK files. Just note I am only getting this on one machine, if it makes any difference it is an i686 system with all VIA chipsets and VIA-C7M NannoBGA2 processor. Any ideas? Thanks -- George H george.dma at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Mon Feb 22 04:43:43 2010 From: george.dma at gmail.com (George H) Date: Mon, 22 Feb 2010 13:43:43 +0200 Subject: [Rxtx] Lingering rxtx process Message-ID: Hi, I am using RXTX v2.1-7. I use it to communicate with 2 serial receipt printers and 1 serial line display device. My program runs well using the RXTX library on Windows and Linux. But... when I installed Linux on another hardware the program does not exit properly. By this I mean that the java program seems to have exited (passed the System.exit(0)) code but the console still does not return to the bash shell. I have to CTRL+C each time to kill the program. And on each restart RXTX has to remove stale LCK files. Just note I am only getting this on one machine, if it makes any difference it is an i686 system with all VIA chipsets and VIA-C7M NannoBGA2 processor. Any ideas? Thanks -- George H george.dma at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Tue Feb 23 01:29:42 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Tue, 23 Feb 2010 09:29:42 +0100 Subject: [Rxtx] Lingering rxtx process In-Reply-To: References: Message-ID: <73a89f361002230029w4a9ec14bt56d654e43c1c9623@mail.gmail.com> 2010/2/22 George H > Hi, > > I am using RXTX v2.1-7. > I use it to communicate with 2 serial receipt printers and 1 serial line > display device. My program runs well using the RXTX library on Windows and > Linux. > But... when I installed Linux on another hardware the program does not exit > properly. By this I mean that the java program seems to have exited (passed > the System.exit(0)) code but the console still does not return to the bash > shell. > > Thread in Noember 2009' - http://mailman.qbang.org/pipermail/rxtx/2009-November/5778408.html I have disocvered one technique which solved this problem in Linux Ubuntu and Mac for RXTX pre2.2, but should helps in 2.1.7 as well. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Thu Feb 25 02:41:46 2010 From: george.dma at gmail.com (George H) Date: Thu, 25 Feb 2010 11:41:46 +0200 Subject: [Rxtx] Lingering rxtx process In-Reply-To: <73a89f361002230029w4a9ec14bt56d654e43c1c9623@mail.gmail.com> References: <73a89f361002230029w4a9ec14bt56d654e43c1c9623@mail.gmail.com> Message-ID: With Mariusz Dec help and with the help of the threads that were mentioned http://mailman.qbang.org/pipermail/rxtx/2009-November/5790326.html http://embeddedfreak.wordpress.com/2008/10/08/rxtx-serial-port-helper/ I managed to solved my problem. I didn't really like it so much. I am not using the InputStream.read(byte[], int, int) method as for me I can break out of reading the stream if I get a '\n' or a 0x00. Either way the below code sample works for me. int data = 0; int len = 0; while(true) { data = commReader.getInputStream().read(); if(data == -1 || data == 0x00 || data == '\n' || commReader.getInputStream().available() < 1) { break; } if(len == buffer.length) { processData(buffer); clearBuffer(); } buffer[len++] = (byte)data; } Before I would loop the while until data != -1. But that blocks on .close() and my program never gets to exit. Adding .available() < 1 as a break condition fixes it when I call .close() I am going to see if this is a linux kernel configuration issue or not cos it isn't so obvious and I hardly ever use .available() when reading streams. Love the project though :) -- George H george.dma at gmail.com On Tue, Feb 23, 2010 at 10:29 AM, Mariusz Dec wrote: > > > 2010/2/22 George H > > Hi, >> >> I am using RXTX v2.1-7. >> I use it to communicate with 2 serial receipt printers and 1 serial line >> display device. My program runs well using the RXTX library on Windows and >> Linux. >> But... when I installed Linux on another hardware the program does not >> exit properly. By this I mean that the java program seems to have exited >> (passed the System.exit(0)) code but the console still does not return to >> the bash shell. >> >> Thread in Noember 2009' - > > http://mailman.qbang.org/pipermail/rxtx/2009-November/5778408.html > > I have disocvered one technique which solved this problem in Linux Ubuntu > and Mac for RXTX pre2.2, but should helps in 2.1.7 as well. > > Regards > Mariusz > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 01:02:21 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 13:32:21 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> My serial port driver(apparently) does not support receive timeout.I registered an event listener for DATA_AVAILABLE. However, the control never seems to come out of the 'while' loop.Shouldn't the InputStream.read return a '-1' immediately if no data is available (this seems to be the default operation)? This was tried on a x86 Linux desktop using rxtx-2.1-7 I've added the snippet for clarity: /******************************************************************************************************************************************************************************/ mySerialPort.enableReceiveThreshold(2000);//Trying to set a time limit for read calls System.out.println(mySerialPort.isReceiveTimeoutEnabled()); // I get FALSE, so its not supported on hardware. mySerialPort.addEventListener(this); mySerialPort.notifyOnDataAvailable(true);//register a event with //my SerialEvent listener implementation: public void serialEvent(SerialPortEvent arg0) { int newData=0; switch(arg0.getEventType()){ case SerialPortEvent.DATA_AVAILABLE: while (newData != -1) { try { newData = is.read();//This should eventually return a -1 if no data is available within a timeout.PROBLEM!! System.out.println("Got a byte from port:"+newData); if (newData == -1) { break; } } catch (IOException ex) { System.err.println(ex); return; } } break; } return; } /******************************************************************************************************************************************************************************/ Thanks and regards, Ravi From michael.erskine at ketech.com Wed Feb 3 02:26:50 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 09:26:50 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From michael.erskine at ketech.com Wed Feb 3 05:03:30 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 12:03:30 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > Michael Erskine > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > > Your event handler should handle the event and return immediately so that its > controlling thread can handle other events. I recommend a single read in the > following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) > reads all available bytes up to the size of the buffer returning the number of > bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } After posting this I considered the glaring possibility of the rawbuf read buffer being too small to receive all the available bytes and perhaps skipping data: after all, I'm guessing that is why we see so many posts asking for help with blocking implementations of read event handlers looping on "while(bytes are available)". I've spent this morning writing an extensive multi-threaded unit test suite that includes tests with a tiny buffer compared to the amount of data available and found that no data was being skipped. I now want to know why! The SerialPortEvent.DATA_AVAILABLE event must be being fired again if there is more data available on the input stream. If that is the case then it should be heavily documented with good examples in the wiki to avoid the types of developer anguish we see so regularly. BTW: I'm not at liberty to post the JUnit tests as they use my company's unit test suite framework. Regards, Michael Erskine. From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 06:18:04 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 18:48:04 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Hello Michael, I tried out your suggestion but the problem is that the read(rawbuf) blocks until the entire length of the rawbuf array has been read (blocking). I cannot decide on a reasonable size of the array because it varies from 2 bytes to as much as 50 byes (i'm communicating with a modem,each response is of a different length), which is why i wanted to use non blocking calls. But on a side note, read(byte[]) in turn calls the read() in a loop.In the native C function, the read is supposed to return a -1 upon timeout.But my driver does not support timeout.The default timeout value is zero and the linux select call upon zero time out causes an infinite wait.What am i missing...... Thanks and regards, Ravi Date: Wed, 3 Feb 2010 09:26:50 +0000 From: Michael Erskine To: "rxtx at qbang.org" Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: Content-Type: text/plain; charset="us-ascii" > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From m.kirkland at comcast.net Wed Feb 3 06:46:03 2010 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 3 Feb 2010 05:46:03 -0800 Subject: [Rxtx] One port blocking another port In-Reply-To: References: Message-ID: <68768633814F4D7D86761D34F0764FE0@bengal.net> It turns out this is caused by having the RTS/CTS flow control turned on and me not providing a true on the RTS pin. Somehow it seems the port timing out on a read allows the write to proceed. This is not an issue for my application but I wonder if the write should not proceed until the RTS pin is true even if a read times out. mk -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Monday, January 25, 2010 7:48 PM To: Mike Kirkland Cc: rxtx at qbang.org Subject: Re: [Rxtx] One port blocking another port On Mon, 25 Jan 2010, Mike Kirkland wrote: > > Hi All, > > ? > > I have a program that reads from one com port and writes to another com > port. It also does the same thing in reverse (reads from the second com port > and writes to the first one. It basically ties two com ports together. > > ? > > One port is very chatty and has a consent stream of data. The other port has > very little data. > > ? > > Both ports use a 5000 ms (5 second) time out. > > ? > > The issue I am having is that is appears that the first port?s write to the > second port is blocked while the second port is waiting for input. The first > port?s write proceeds only after the second port has timed out. > > ? > > I suppose I could have something twisted around in my code but I was > wondering if this is a know issue? > Hi Kirk, I've not seen a report like this. Perhaps some simple reproduction code will reveal a problem on your end or help us identify a problem in rxtx. I think there are several users doing multiport communication. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Wed Feb 3 07:03:58 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:03:58 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Message-ID: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> 2010/2/3 Ravishankar N > Hello Michael, > [..] > But on a side note, read(byte[]) in turn calls the read() in a loop.In the > native C function, the read is supposed to return a -1 upon timeout.But my > driver > does not support timeout.The default timeout value is zero and the linux > select call upon zero time out causes an infinite wait.What am i > missing...... > > When I have tested RXTX between platforms, I have observed "hangup" inside JNI driver when no data in Linux, is normal thing. Solution was setting the timeout for RXTX when no data from JNI driver. Something like that: commPort.enableReceiveTimeout(10); And it works perfect.... The only difference is that I am NOT using events - I am using continous read in separate thread and if data is available, is parsed and transferred to application using exception. Regards Mariusz > Thanks and regards, > Ravi > > Date: Wed, 3 Feb 2010 09:26:50 +0000 > From: Michael Erskine > To: "rxtx at qbang.org" > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > Message-ID: > > > Content-Type: text/plain; charset="us-ascii" > > > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of > > Ravishankar N > > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > > > My serial port driver(apparently) does not support receive timeout.I > > registered an event listener for DATA_AVAILABLE. However, the control > never > > seems to come out of the 'while' loop.Shouldn't the > > InputStream.read return a '-1' immediately if no data is available (this > seems > > to be the default operation)? > > Your event handler should handle the event and return immediately so that > its controlling thread can handle other events. I recommend a single read in > the following manner: rawbuf is a byte[] of "reasonable" size and the > read(byte[]) reads all available bytes up to the size of the buffer > returning the number of bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } > > This style of reading has worked for me with RXTX on Linux and Windows XP > for a good few years now in railway industry communications systems. Any > timeouts (largely unnecessary in my applications) can be handled elsewhere, > usually at a higher layer. > > Regards, > Michael Erskine. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Feb 3 07:22:55 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 3 Feb 2010 09:22:55 -0500 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: I'm guessing that this is driver specific. I recently had to support a select()/poll() infrastructure for a linux serial DD, its certainly non trivial to support async IO, so I suspect the problem in this case has to do with missing poll infrastructure in the device driver. This also has to coupled with special open flags for the device (which is within the rxtx code) The key routines within a 2.6 kernel linux device driver are shown below (if you have access to it for your particular device) are indicated below (here is a snippet from my device driver c code that supports polling/select). User space code to test this shown below also, note that the device needs to be opened with the O_NONBLOCK option to support the select/poll api // device driver code ..... /* * File operations supported by this driver. */ static struct file_operations iop_fops = { .owner = THIS_MODULE, .check_flags= iop_check_flags, .ioctl = iop_ioctl, .open = iop_open, .poll = iop_poll, // SUPPORT FOR SELECT/POLL infrastructure .read = iop_read, .release = iop_release, .write = iop_write, }; /** * Select/poll/epoll infrastructure. * * @param file * @param wait * * @return */ static unsigned int iop_poll(struct file *filp, poll_table *wait) { struct iop_device *devp = (struct iop_device *)filp->private_data; // the poll_table wait arg is an opaque pointer poll_wait(filp, &devp->readq, wait); // return from poll indicating whether we have read/write data unsigned int mask = 0; if (kfifo_len(devp->rx_fifo)) { mask |= (POLLIN | POLLRDNORM); } // @JC We don't do select on write yet // if (kfifo_len(devp->tx_fifo)) { // mask |= (POLLOUT | POLLWRNORM); // } // Only print out while debugging // if (mask != 0) { // printk (KERN_INFO "%s: [%04x]\n", __FUNCTION__, mask); // } return mask; } /** * device driver blocking and non blocking read function. This * function reads the requested number of bytes from the read * kfifo blocking as required. * * @param filp * @param buf * @param count * @param f_pos * * @return */ static ssize_t iop_read(struct file *filp, char __user *buf, size_t count, loff_t * ppos) { // access appropriate device struct struct iop_device *devp = (struct iop_device *) filp->private_data; ssize_t retval; // support non blocking mode (default) by checking if the kfifo is empty first if ((kfifo_len(devp->rx_fifo)==0) && (filp->f_flags & O_NONBLOCK)) { return -EAGAIN; } // wait for rx_fifo to receive data via receive interrupts retval = wait_event_interruptible(devp->readq, kfifo_len(devp->rx_fifo) != 0); // check for some error condition if (retval) { printk (KERN_ERR "%s: wait_event_interruptible returned[%d]\n", __FUNCTION__, retval); return retval; } // copy max requested bytes from rx_fifo to device buffer // this may still leave bytes in the kfifo for a subsequent read // if we are reading in a loop retval = kfifo_get(devp->rx_fifo, devp->rxbuf, count); // printk (KERN_INFO "%s: [%d] byte(s)\n", __FUNCTION__, retval); if (copy_to_user(buf, devp->rxbuf, retval)) { printk (KERN_ERR "%s: problem copying rx_fifo data to user buffer\n", __FUNCTION__); return -EFAULT; } return retval; } // a selection of my user space code reading via select()/poll()..... // user space open code iop_fd = ::open( deviceName.data(), O_RDWR | O_NONBLOCK); while ((bytes_to_expect - bytes_read) > 0) { // must reinitialize these between select calls fd_set readfds; FD_ZERO( &readfds ); FD_SET( iop_fd, &readfds ); // 1s sec read polling timeout struct timeval timeout; timeout.tv_sec = 1; timeout.tv_usec = 0; int rc = select( FD_SETSIZE, &readfds, NULL, NULL, &timeout ); // read from file when descriptor // indicates data available without blocking if ((rc > 0) && FD_ISSET(iop_fd, &readfds)) { // read into the appropriate offset within the rx_buf int temp = read(iop_fd, rx_buf + bytes_read, bytes_to_expect - bytes_read); if (!temp) { printf("EOF detected with %d bytes expected\n", bytes_to_expect - bytes_read); } else { bytes_read += temp; } } else if (rc < 0){ printf("%s: select on [%s], bytes_read[%d], errno=%d\n", __FUNCTION__, thread_args->device, bytes_read, errno); } else { printf("%s: select on [%s], bytes_read[%d], timeout\n", __FUNCTION__, thread_args->device, bytes_read); } } On Wed, Feb 3, 2010 at 9:03 AM, Mariusz Dec wrote: > > > 2010/2/3 Ravishankar N > >> Hello Michael, >> [..] >> >> But on a side note, read(byte[]) in turn calls the read() in a loop.In the >> native C function, the read is supposed to return a -1 upon timeout.But my >> driver >> does not support timeout.The default timeout value is zero and the linux >> select call upon zero time out causes an infinite wait.What am i >> missing...... >> >> > When I have tested RXTX between platforms, I have observed "hangup" inside > JNI driver when no data in Linux, is normal thing. > > Solution was setting the timeout for RXTX when no data from JNI driver. > > Something like that: > > commPort.enableReceiveTimeout(10); > > And it works perfect.... > > The only difference is that I am NOT using events - I am using continous > read in separate thread and if data is available, is parsed and transferred > to application using exception. > > Regards > Mariusz > > > >> Thanks and regards, >> Ravi >> >> Date: Wed, 3 Feb 2010 09:26:50 +0000 >> From: Michael Erskine >> To: "rxtx at qbang.org" >> Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? >> Message-ID: >> >> >> Content-Type: text/plain; charset="us-ascii" >> >> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >> Of >> > Ravishankar N >> > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? >> > >> > My serial port driver(apparently) does not support receive timeout.I >> > registered an event listener for DATA_AVAILABLE. However, the control >> never >> > seems to come out of the 'while' loop.Shouldn't the >> > InputStream.read return a '-1' immediately if no data is available (this >> seems >> > to be the default operation)? >> >> Your event handler should handle the event and return immediately so that >> its controlling thread can handle other events. I recommend a single read in >> the following manner: rawbuf is a byte[] of "reasonable" size and the >> read(byte[]) reads all available bytes up to the size of the buffer >> returning the number of bytes actually read... >> >> case SerialPortEvent.DATA_AVAILABLE: >> try { >> int i = is.read(rawbuf); >> if (i == -1) { >> << process EOF condition - should never happen >> >> return; >> } >> << process bytes (rawbuf, i); >> >> return; >> } catch (IOException e) { >> << promptly deal with exception >> >> return; >> } >> >> This style of reading has worked for me with RXTX on Linux and Windows XP >> for a good few years now in railway industry communications systems. Any >> timeouts (largely unnecessary in my applications) can be handled elsewhere, >> usually at a higher layer. >> >> Regards, >> Michael Erskine. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Feb 3 07:33:27 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:33:27 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: <73a89f361002030633j682610afia48dc7accd8e049b@mail.gmail.com> 2010/2/3 John Coffey > I'm guessing that this is driver specific. I recently had to support a > select()/poll() infrastructure for a linux serial DD, its certainly non > trivial to support async IO, so I suspect the problem in this case has to do > with missing poll infrastructure in the device driver. This also has to > coupled with special open flags for the device (which is within the rxtx > code) > > Yes, you are right, it may be driver specific, but in my case I haven't changed blocking JNI driver. I have added ONLY one call to RXTX method mentioned in my previous post and blocking (as seen as from Java app) gone out... Maybe this is not elegant, but works without problem in my app. I am using only FTDI chips and their drivers from couple of years and maybe this is the kind of the way to have no many problems with serial as well? Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From andyrxtx at g0poy.co.uk Wed Feb 3 11:09:04 2010 From: andyrxtx at g0poy.co.uk (andyrxtx at g0poy.co.uk) Date: Wed, 3 Feb 2010 18:09:04 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes Message-ID: <20100203180904.164f24dd@workstation.site> ?Hello RXTX group, I have just joined this group, and this is my first posting. I wanted to pass on some information regarding rxtx, so apologies if this has been brought up before. I have searched back through the archives but nothing specific came up. I am not a Java programmer, and I only came across rxtx a few days ago. I use a piece of test equipment called a miniVNA http://www.miniradiosolutions.com/ This is a serial USB controlled instrument, and it has control software available for MS windows, and a very old and now non-working Linux application. A few days ago Dietmar, DL2SBA released a Java application to control the miniVNA, obviously this application makes use of rxtx. The program worked fine on Windows, so I set about installing it onto Linux. I use SUSE11.1 After a few false starts, I got the system running fairly easily, sorting out the file locking by adding the uucp group to the users account as suggested (I used the 2.2pre binary files) I then passed the install instructions onto another miniVNA user, who also uses SUSE, but he ran into problems. To cut a long story short, he was also having file lock problems, but the uucp fix did not work. Digging into his system I found that there have been some changes in SUSE 11.2. tty ports are now assigned to the dialout group rather than uucp. A hint in the rxtx INSTALL file, suggested that var/lock needs to be checked, so: SUSE 11.1, var/lock is root:uucp SUSE 11.2 var/lock is root:root A search on Google brought up several comments regarding this, and also a bugzilla entry. https://bugzilla.novell.com/show_bug.cgi?id=552095 However from reading the various posts, some of which are in the bugzilla entry, it appears that many distros may be, or have changed to this configuration, and this will undoubtedly break several things, rxtx included. I solved my fellow SUSE users problem by compiling the rxtx libs with the no lock file option during configure, and that solved his problem. As this issue will probably take some time to get resolved across all the various Linux distros, it might be worth considering changing the default on the Linux build of rxtx not to use lockfiles, or provide the two versions of the lib in the binary archive. Thanks for your indulgence Andy From damorales at gmail.com Wed Feb 3 11:33:23 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 15:33:23 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203180904.164f24dd@workstation.site> References: <20100203180904.164f24dd@workstation.site> Message-ID: Hi I had the same problem in Mandriva 2010 and yes, adding the user to the uucp group did not work as it used to be in earlier versions of linux distros, causing RXTX to not work as non root user. The problem appears because the existense of UDEV, now you MUST add a RULE so the group (uucp or whatever) have access (Read, Write, Execute) to the Serial Port. To solve the problem, without needing to recompile RXTX, you must add a rule to grant permissions (0666) to the group for the device or port (tty*, ttyUSB*, etc). I do not remember now what is the line i added but when i come back home i will give it to you (i am at work now). Greetings ! 2010/2/3 > Hello RXTX group, > > I have just joined this group, and this is my first posting. > I wanted to pass on some information regarding rxtx, so apologies if > this has been brought up before. I have searched back through the > archives but nothing specific came up. > > I am not a Java programmer, and I only came across rxtx a few days ago. > > I use a piece of test equipment called a miniVNA > http://www.miniradiosolutions.com/ > > This is a serial USB controlled instrument, and it has control software > available for MS windows, and a very old and now non-working Linux > application. > > A few days ago Dietmar, DL2SBA released a Java application to control the > miniVNA, obviously this application makes use of rxtx. > > The program worked fine on Windows, so I set about installing it onto > Linux. I use SUSE11.1 After a few false starts, I got the system running > fairly easily, sorting out the file locking by adding the uucp group to > the users account as suggested (I used the 2.2pre binary files) I then > passed the install instructions onto another miniVNA user, who also uses > SUSE, but he ran into problems. To cut a long story short, he was > also having file lock problems, but the uucp fix did not work. Digging > into his system I found that there have been some changes in SUSE 11.2. > > tty ports are now assigned to the dialout group rather than uucp. > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > checked, so: > > SUSE 11.1, var/lock is root:uucp > SUSE 11.2 var/lock is root:root > > A search on Google brought up several comments regarding this, and also > a bugzilla entry. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > However from reading the various posts, some of which are in the bugzilla > entry, it appears that many distros may be, or have changed to this > configuration, and this will undoubtedly break several things, rxtx > included. > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > no lock file option during configure, and that solved his problem. > > As this issue will probably take some time to get resolved across all the > various Linux distros, it might be worth considering changing the default > on the Linux build of rxtx not to use lockfiles, or provide the two > versions of the lib in the binary archive. > > Thanks for your indulgence > > Andy > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Wed Feb 3 12:07:02 2010 From: andy at g0poy.com (Andy Eskelson) Date: Wed, 3 Feb 2010 19:07:02 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> Message-ID: <20100203190702.1b0e7015@workstation.site> Thanks Daniel, I am aware of the permissions problem, I have had a udev rules to solve this for other programs for some time. . I don't think that this is the same problem. as far as I can understand things, the lock files are written in var/lock. Previously var/lock and dev/tty-whatever were the same group. Now with var/lock owned by and with a group of root:root anything other than root cannot create a lock file. Even minicom is broken by this change. This change is going to have quite a few knock-on effects I think. Andy On Wed, 3 Feb 2010 15:33:23 -0300 Daniel Morales Salas wrote: > Hi > > I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > group did not work as it used to be in earlier versions of linux distros, > causing RXTX to not work as non root user. > > The problem appears because the existense of UDEV, now you MUST add a RULE > so the group (uucp or whatever) have access (Read, Write, Execute) to the > Serial Port. > > To solve the problem, without needing to recompile RXTX, you must add a rule > to grant permissions (0666) to the group for the device or port (tty*, > ttyUSB*, etc). I do not remember now what is the line i added but when i > come back home i will give it to you (i am at work now). > > Greetings ! > > 2010/2/3 > > > Hello RXTX group, > > > > I have just joined this group, and this is my first posting. > > I wanted to pass on some information regarding rxtx, so apologies if > > this has been brought up before. I have searched back through the > > archives but nothing specific came up. > > > > I am not a Java programmer, and I only came across rxtx a few days ago. > > > > I use a piece of test equipment called a miniVNA > > http://www.miniradiosolutions.com/ > > > > This is a serial USB controlled instrument, and it has control software > > available for MS windows, and a very old and now non-working Linux > > application. > > > > A few days ago Dietmar, DL2SBA released a Java application to control the > > miniVNA, obviously this application makes use of rxtx. > > > > The program worked fine on Windows, so I set about installing it onto > > Linux. I use SUSE11.1 After a few false starts, I got the system running > > fairly easily, sorting out the file locking by adding the uucp group to > > the users account as suggested (I used the 2.2pre binary files) I then > > passed the install instructions onto another miniVNA user, who also uses > > SUSE, but he ran into problems. To cut a long story short, he was > > also having file lock problems, but the uucp fix did not work. Digging > > into his system I found that there have been some changes in SUSE 11.2. > > > > tty ports are now assigned to the dialout group rather than uucp. > > > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > checked, so: > > > > SUSE 11.1, var/lock is root:uucp > > SUSE 11.2 var/lock is root:root > > > > A search on Google brought up several comments regarding this, and also > > a bugzilla entry. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > However from reading the various posts, some of which are in the bugzilla > > entry, it appears that many distros may be, or have changed to this > > configuration, and this will undoubtedly break several things, rxtx > > included. > > > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > > no lock file option during configure, and that solved his problem. > > > > As this issue will probably take some time to get resolved across all the > > various Linux distros, it might be worth considering changing the default > > on the Linux build of rxtx not to use lockfiles, or provide the two > > versions of the lib in the binary archive. > > > > Thanks for your indulgence > > > > Andy > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From thisdyingdream at gmail.com Wed Feb 3 12:32:35 2010 From: thisdyingdream at gmail.com (Steven Harms) Date: Wed, 3 Feb 2010 14:32:35 -0500 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203190702.1b0e7015@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: This is currently a bug in OpenSUSE that affects more than just rxtx, and is a result of unified udev rules. You can work around this by making udev change the group back to uucp until something more happens. https://bugzilla.novell.com/show_bug.cgi?id=552095 Thanks, Steve On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > Thanks Daniel, > > I am aware of the permissions problem, I have had a udev rules to solve > this for other programs for some time. > . > I don't think that this is the same problem. as far as I can understand > things, the lock files are written in var/lock. Previously var/lock and > dev/tty-whatever were the same group. Now with var/lock owned by and with > a group of root:root anything other than root cannot create a lock > file. Even minicom is broken by this change. > > This change is going to have quite a few knock-on effects I think. > > > Andy > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > Daniel Morales Salas wrote: > >> Hi >> >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp >> group did not work as it used to be in earlier versions of linux distros, >> causing RXTX to not work as non root user. >> >> The problem appears because the existense of UDEV, now you MUST add a RULE >> so the group (uucp or whatever) have access (Read, Write, Execute) to the >> Serial Port. >> >> To solve the problem, without needing to recompile RXTX, you must add a rule >> to grant permissions (0666) to the group for the device or port (tty*, >> ttyUSB*, etc). I do not remember now what is the line i added but when i >> come back home i will give it to you (i am at work now). >> >> Greetings ! >> >> 2010/2/3 >> >> > Hello RXTX group, >> > >> > I have just joined this group, and this is my first posting. >> > I wanted to pass on ?some information regarding rxtx, so apologies if >> > this has been brought up before. I have searched back through the >> > archives but nothing specific came up. >> > >> > I am not a Java programmer, and I only came across rxtx a few days ago. >> > >> > I use a piece of test equipment called a miniVNA >> > http://www.miniradiosolutions.com/ >> > >> > This is a serial USB controlled instrument, and it has control software >> > available for MS windows, and a very old and now non-working Linux >> > application. >> > >> > A few days ago Dietmar, DL2SBA released a Java application to control the >> > miniVNA, obviously this application makes use of rxtx. >> > >> > The program worked fine on Windows, so I set about installing it onto >> > Linux. I use SUSE11.1 After a few false starts, I got the system running >> > fairly easily, sorting out the file locking by adding the uucp group to >> > the users account as suggested (I used the 2.2pre binary files) I then >> > passed the install instructions onto another miniVNA user, who also uses >> > SUSE, but he ran into problems. To cut a long story short, he was >> > also having file lock problems, but the uucp fix did not work. Digging >> > into his system I found that there have been some changes in SUSE 11.2. >> > >> > tty ports are now assigned to the dialout group rather than uucp. >> > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be >> > checked, so: >> > >> > SUSE 11.1, var/lock is root:uucp >> > SUSE 11.2 var/lock is root:root >> > >> > A search on Google brought up several comments regarding this, and also >> > a ?bugzilla entry. >> > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 >> > >> > However from reading the various posts, some of which are in the bugzilla >> > entry, it appears that many distros may be, or have changed to this >> > configuration, and this will undoubtedly break several things, rxtx >> > included. >> > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the >> > no lock file option during configure, and that solved his problem. >> > >> > As this issue will probably take some time to get resolved across all the >> > various Linux distros, it might be worth considering changing the default >> > on the Linux build of rxtx not to use lockfiles, or provide the two >> > versions of the lib in the binary archive. >> > >> > Thanks for your indulgence >> > >> > Andy >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> >> >> >> -- >> Atte: >> Daniel Dario Morales Salas >> Ingeniero Civil en Computaci?n e Inform?tica >> Tel?fono: 02 684 3417 >> Celular: 09 643 1802 >> Santiago, Chile > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 WWW: http://www.sharms.org/blog From andy at g0poy.com Wed Feb 3 17:58:29 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 00:58:29 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: <20100204005829.7dc944e1@workstation.site> Thanks Steve, changing the serial ports back the uucp is not a big problem. I have a udev rule that can be easily modified already. However I cannot see any way of dealing with the var/lock problem apart from making it writable to all. Any thoughts? Andy On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms wrote: > This is currently a bug in OpenSUSE that affects more than just rxtx, > and is a result of unified udev rules. You can work around this by > making udev change the group back to uucp until something more > happens. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > Thanks, > > Steve > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > Thanks Daniel, > > > > I am aware of the permissions problem, I have had a udev rules to solve > > this for other programs for some time. > > . > > I don't think that this is the same problem. as far as I can understand > > things, the lock files are written in var/lock. Previously var/lock and > > dev/tty-whatever were the same group. Now with var/lock owned by and with > > a group of root:root anything other than root cannot create a lock > > file. Even minicom is broken by this change. > > > > This change is going to have quite a few knock-on effects I think. > > > > > > Andy > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > Daniel Morales Salas wrote: > > > >> Hi > >> > >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > >> group did not work as it used to be in earlier versions of linux distros, > >> causing RXTX to not work as non root user. > >> > >> The problem appears because the existense of UDEV, now you MUST add a RULE > >> so the group (uucp or whatever) have access (Read, Write, Execute) to the > >> Serial Port. > >> > >> To solve the problem, without needing to recompile RXTX, you must add a rule > >> to grant permissions (0666) to the group for the device or port (tty*, > >> ttyUSB*, etc). I do not remember now what is the line i added but when i > >> come back home i will give it to you (i am at work now). > >> > >> Greetings ! > >> > >> 2010/2/3 > >> > >> > Hello RXTX group, > >> > > >> > I have just joined this group, and this is my first posting. > >> > I wanted to pass on ?some information regarding rxtx, so apologies if > >> > this has been brought up before. I have searched back through the > >> > archives but nothing specific came up. > >> > > >> > I am not a Java programmer, and I only came across rxtx a few days ago. > >> > > >> > I use a piece of test equipment called a miniVNA > >> > http://www.miniradiosolutions.com/ > >> > > >> > This is a serial USB controlled instrument, and it has control software > >> > available for MS windows, and a very old and now non-working Linux > >> > application. > >> > > >> > A few days ago Dietmar, DL2SBA released a Java application to control the > >> > miniVNA, obviously this application makes use of rxtx. > >> > > >> > The program worked fine on Windows, so I set about installing it onto > >> > Linux. I use SUSE11.1 After a few false starts, I got the system running > >> > fairly easily, sorting out the file locking by adding the uucp group to > >> > the users account as suggested (I used the 2.2pre binary files) I then > >> > passed the install instructions onto another miniVNA user, who also uses > >> > SUSE, but he ran into problems. To cut a long story short, he was > >> > also having file lock problems, but the uucp fix did not work. Digging > >> > into his system I found that there have been some changes in SUSE 11.2. > >> > > >> > tty ports are now assigned to the dialout group rather than uucp. > >> > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > >> > checked, so: > >> > > >> > SUSE 11.1, var/lock is root:uucp > >> > SUSE 11.2 var/lock is root:root > >> > > >> > A search on Google brought up several comments regarding this, and also > >> > a ?bugzilla entry. > >> > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > >> > > >> > However from reading the various posts, some of which are in the bugzilla > >> > entry, it appears that many distros may be, or have changed to this > >> > configuration, and this will undoubtedly break several things, rxtx > >> > included. > >> > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the > >> > no lock file option during configure, and that solved his problem. > >> > > >> > As this issue will probably take some time to get resolved across all the > >> > various Linux distros, it might be worth considering changing the default > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > >> > versions of the lib in the binary archive. > >> > > >> > Thanks for your indulgence > >> > > >> > Andy > >> > > >> > _______________________________________________ > >> > Rxtx mailing list > >> > Rxtx at qbang.org > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > >> > >> > >> > >> -- > >> Atte: > >> Daniel Dario Morales Salas > >> Ingeniero Civil en Computaci?n e Inform?tica > >> Tel?fono: 02 684 3417 > >> Celular: 09 643 1802 > >> Santiago, Chile > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > WWW: http://www.sharms.org/blog From damorales at gmail.com Wed Feb 3 18:26:38 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 22:26:38 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100204005829.7dc944e1@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: Hello I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva 2010 this is what i get: drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ and i don't have ANY problem with lock files and RXTX in my java software. All i had to do was add this rule to udev: # serial KERNEL=="tty*", GROUP="uucp", MODE="0666" and that was all. Of course my user (metalklesk) is part of uucp group. I did not make /var/lock writable to all users. Greetings ! 2010/2/3 Andy Eskelson > Thanks Steve, > > changing the serial ports back the uucp is not a big problem. I have a > udev rule that can be easily modified already. However I cannot see any > way of dealing with the var/lock problem apart from making it writable to > all. Any thoughts? > > Andy > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > wrote: > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > and is a result of unified udev rules. You can work around this by > > making udev change the group back to uucp until something more > > happens. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > Thanks, > > > > Steve > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > Thanks Daniel, > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > this for other programs for some time. > > > . > > > I don't think that this is the same problem. as far as I can understand > > > things, the lock files are written in var/lock. Previously var/lock and > > > dev/tty-whatever were the same group. Now with var/lock owned by and > with > > > a group of root:root anything other than root cannot create a lock > > > file. Even minicom is broken by this change. > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > Daniel Morales Salas wrote: > > > > > >> Hi > > >> > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > the uucp > > >> group did not work as it used to be in earlier versions of linux > distros, > > >> causing RXTX to not work as non root user. > > >> > > >> The problem appears because the existense of UDEV, now you MUST add a > RULE > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > the > > >> Serial Port. > > >> > > >> To solve the problem, without needing to recompile RXTX, you must add > a rule > > >> to grant permissions (0666) to the group for the device or port (tty*, > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > i > > >> come back home i will give it to you (i am at work now). > > >> > > >> Greetings ! > > >> > > >> 2010/2/3 > > >> > > >> > Hello RXTX group, > > >> > > > >> > I have just joined this group, and this is my first posting. > > >> > I wanted to pass on some information regarding rxtx, so apologies > if > > >> > this has been brought up before. I have searched back through the > > >> > archives but nothing specific came up. > > >> > > > >> > I am not a Java programmer, and I only came across rxtx a few days > ago. > > >> > > > >> > I use a piece of test equipment called a miniVNA > > >> > http://www.miniradiosolutions.com/ > > >> > > > >> > This is a serial USB controlled instrument, and it has control > software > > >> > available for MS windows, and a very old and now non-working Linux > > >> > application. > > >> > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > control the > > >> > miniVNA, obviously this application makes use of rxtx. > > >> > > > >> > The program worked fine on Windows, so I set about installing it > onto > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > running > > >> > fairly easily, sorting out the file locking by adding the uucp group > to > > >> > the users account as suggested (I used the 2.2pre binary files) I > then > > >> > passed the install instructions onto another miniVNA user, who also > uses > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > >> > also having file lock problems, but the uucp fix did not work. > Digging > > >> > into his system I found that there have been some changes in SUSE > 11.2. > > >> > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > >> > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > >> > checked, so: > > >> > > > >> > SUSE 11.1, var/lock is root:uucp > > >> > SUSE 11.2 var/lock is root:root > > >> > > > >> > A search on Google brought up several comments regarding this, and > also > > >> > a bugzilla entry. > > >> > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > >> > > > >> > However from reading the various posts, some of which are in the > bugzilla > > >> > entry, it appears that many distros may be, or have changed to this > > >> > configuration, and this will undoubtedly break several things, rxtx > > >> > included. > > >> > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > with the > > >> > no lock file option during configure, and that solved his problem. > > >> > > > >> > As this issue will probably take some time to get resolved across > all the > > >> > various Linux distros, it might be worth considering changing the > default > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > >> > versions of the lib in the binary archive. > > >> > > > >> > Thanks for your indulgence > > >> > > > >> > Andy > > >> > > > >> > _______________________________________________ > > >> > Rxtx mailing list > > >> > Rxtx at qbang.org > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > >> > > > >> > > >> > > >> > > >> -- > > >> Atte: > > >> Daniel Dario Morales Salas > > >> Ingeniero Civil en Computaci?n e Inform?tica > > >> Tel?fono: 02 684 3417 > > >> Celular: 09 643 1802 > > >> Santiago, Chile > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at qbang.org > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > -- > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > WWW: http://www.sharms.org/blog > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Thu Feb 4 05:31:46 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 12:31:46 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: <20100204123146.6cffeb67@workstation.site> Thank's for the confirmation. Something odd is going on somewhere in SUSE 11.2. I'll have to build up a local SUSE11.2 system to see if I can nail down exactly what is going on. Something is blocking the lockfiles in var/lock. The net is nice, but it's a bit difficult trying to work out what is going on what the machine in question is in Germany and I'm in the UK :-) Andy On Wed, 3 Feb 2010 22:26:38 -0300 Daniel Morales Salas wrote: > Hello > > I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva > 2010 this is what i get: > > drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ > > and i don't have ANY problem with lock files and RXTX in my java software. > All i had to do was add this rule to udev: > > # serial > KERNEL=="tty*", GROUP="uucp", MODE="0666" > > and that was all. Of course my user (metalklesk) is part of uucp group. > I did not make /var/lock writable to all users. > > Greetings ! > > 2010/2/3 Andy Eskelson > > > Thanks Steve, > > > > changing the serial ports back the uucp is not a big problem. I have a > > udev rule that can be easily modified already. However I cannot see any > > way of dealing with the var/lock problem apart from making it writable to > > all. Any thoughts? > > > > Andy > > > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > > wrote: > > > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > > and is a result of unified udev rules. You can work around this by > > > making udev change the group back to uucp until something more > > > happens. > > > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > > > Thanks, > > > > > > Steve > > > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > > Thanks Daniel, > > > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > > this for other programs for some time. > > > > . > > > > I don't think that this is the same problem. as far as I can understand > > > > things, the lock files are written in var/lock. Previously var/lock and > > > > dev/tty-whatever were the same group. Now with var/lock owned by and > > with > > > > a group of root:root anything other than root cannot create a lock > > > > file. Even minicom is broken by this change. > > > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > > Daniel Morales Salas wrote: > > > > > > > >> Hi > > > >> > > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > > the uucp > > > >> group did not work as it used to be in earlier versions of linux > > distros, > > > >> causing RXTX to not work as non root user. > > > >> > > > >> The problem appears because the existense of UDEV, now you MUST add a > > RULE > > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > > the > > > >> Serial Port. > > > >> > > > >> To solve the problem, without needing to recompile RXTX, you must add > > a rule > > > >> to grant permissions (0666) to the group for the device or port (tty*, > > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > > i > > > >> come back home i will give it to you (i am at work now). > > > >> > > > >> Greetings ! > > > >> > > > >> 2010/2/3 > > > >> > > > >> > Hello RXTX group, > > > >> > > > > >> > I have just joined this group, and this is my first posting. > > > >> > I wanted to pass on some information regarding rxtx, so apologies > > if > > > >> > this has been brought up before. I have searched back through the > > > >> > archives but nothing specific came up. > > > >> > > > > >> > I am not a Java programmer, and I only came across rxtx a few days > > ago. > > > >> > > > > >> > I use a piece of test equipment called a miniVNA > > > >> > http://www.miniradiosolutions.com/ > > > >> > > > > >> > This is a serial USB controlled instrument, and it has control > > software > > > >> > available for MS windows, and a very old and now non-working Linux > > > >> > application. > > > >> > > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > > control the > > > >> > miniVNA, obviously this application makes use of rxtx. > > > >> > > > > >> > The program worked fine on Windows, so I set about installing it > > onto > > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > > running > > > >> > fairly easily, sorting out the file locking by adding the uucp group > > to > > > >> > the users account as suggested (I used the 2.2pre binary files) I > > then > > > >> > passed the install instructions onto another miniVNA user, who also > > uses > > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > > >> > also having file lock problems, but the uucp fix did not work. > > Digging > > > >> > into his system I found that there have been some changes in SUSE > > 11.2. > > > >> > > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > > >> > > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > > >> > checked, so: > > > >> > > > > >> > SUSE 11.1, var/lock is root:uucp > > > >> > SUSE 11.2 var/lock is root:root > > > >> > > > > >> > A search on Google brought up several comments regarding this, and > > also > > > >> > a bugzilla entry. > > > >> > > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > >> > > > > >> > However from reading the various posts, some of which are in the > > bugzilla > > > >> > entry, it appears that many distros may be, or have changed to this > > > >> > configuration, and this will undoubtedly break several things, rxtx > > > >> > included. > > > >> > > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > > with the > > > >> > no lock file option during configure, and that solved his problem. > > > >> > > > > >> > As this issue will probably take some time to get resolved across > > all the > > > >> > various Linux distros, it might be worth considering changing the > > default > > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > > >> > versions of the lib in the binary archive. > > > >> > > > > >> > Thanks for your indulgence > > > >> > > > > >> > Andy > > > >> > > > > >> > _______________________________________________ > > > >> > Rxtx mailing list > > > >> > Rxtx at qbang.org > > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > > >> > > > > >> > > > >> > > > >> > > > >> -- > > > >> Atte: > > > >> Daniel Dario Morales Salas > > > >> Ingeniero Civil en Computaci?n e Inform?tica > > > >> Tel?fono: 02 684 3417 > > > >> Celular: 09 643 1802 > > > >> Santiago, Chile > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at qbang.org > > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > > > -- > > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > > > WWW: http://www.sharms.org/blog > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From Bob_Jacobsen at lbl.gov Thu Feb 4 09:26:49 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Thu, 4 Feb 2010 08:26:49 -0800 Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 Message-ID: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're using RXTX-2.2pre2, although it emits the known message about "Version mismatch". WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 After the usual messing around, we've got it working on 11 Windows versions, multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ have things working rarely say so, so I don't know whether anybody has gotten it to work on 10.4 or not. The problem encountered is this: dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib dyld: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib followed by the JVM crashing hard. I've got those dump files if that would help. Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If so, is there a patch I can get and build? Thanks Bob -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From tjarvi at qbang.org Thu Feb 4 14:22:21 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 4 Feb 2010 14:22:21 -0700 (MST) Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 In-Reply-To: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> References: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> Message-ID: On Thu, 4 Feb 2010, Bob Jacobsen wrote: > We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're > using RXTX-2.2pre2, although it emits the known message about "Version > mismatch". > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > > After the usual messing around, we've got it working on 11 Windows versions, > multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with > a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ > have things working rarely say so, so I don't know whether anybody has gotten > it to work on 10.4 or not. > > The problem encountered is this: > > dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > dyld: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > followed by the JVM crashing hard. I've got those dump files if that would > help. > > Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If > so, is there a patch I can get and build? > Hi Bob, I talked to a coworker about the problem you ran into. It appears that it is possible to target 'older' Mac systems through makefile configuration changes. "Configuring a Makefile-Based Project If you have a makefile-based project, you can also take advantage of SDK-based development, by adding the appropriate options to your compile and link commands. Using SDKs in makefile-based projects requires GCC 4.0 or later. To choose an SDK, you use the -isysroot option with the compiler and the -syslibroot option with the linker. Both options require that you specify the full path to the desired SDK directory. To set the Deployment OS version in a makefile, use a makefile variable of the form: ENVP= MACOSX_DEPLOYMENT_TARGET=10.4. To use this variable in your makefile, include it in front of your compile and link commands." http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html Or build on the oldest system you want to support. -- Trent Jarvi tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Thu Feb 4 14:56:19 2010 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Thu, 4 Feb 2010 14:56:19 -0700 Subject: [Rxtx] RXTX on 64 Bit Redhat In-Reply-To: References: <4ec9eab61001281448g3dd84910r867619948a4e0d7a@mail.gmail.com> Message-ID: Trent -- Finally fixed all my build related issues. I ran into another issue. On one of my machines my JDK is returning multiple folders for the "java.ext.dirs" (java.ext.dirs -> /opt/jdk1.6.0_17/jre/lib/ext:/usr/java/packages/lib/ext) system property. As a result my JVM wasn't able to detect the gnu.io.rxtx.properties. I am attaching a patch for RXTXCommDriver.java file to check for multiple locations. Also i have to assign permission 660 to all my dev ports to be located by RXTX. Pawan ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 5:12 PM To: Trent Jarvi Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Here is the error i get when i build the src from release-2-1-7 -bash-3.2$ make ( \ \ cd i686-pc-linux-gnu; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/ jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I/opt/jav a1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec - c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialImp.lo;\ if [ "Serial" = "Serial" ]; then \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I /opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_tim espec -c /home/jb_stg/rxtx/rxtx-devel/./src/fuserImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ else \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo; \ fi; \ ) gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/inclu de -I/opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need _timespec -c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -fPIC -DPIC -o /hom e/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/.libs/SerialImp.o /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:25:29: error: gnu_io_RXTXPort.h: No such file or directory In file included from /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:113: /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:91: error: expected specifier-qua lifier-list before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'jobject' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:408: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:409: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:410: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:411: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:415: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:416: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:417: error: expected '=', ',', '; ', 'asm' or '__attribute__' before 'is_interrupted' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:418: error: expected declaration specifiers or '...' before 'jint' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:424: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:441: error: expected ')' before ' *' token ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 4:57 PM To: Santosh Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Santosh -- Thank you. That fixed the issue. All -- What CVS branch or release should i use to get the latest RXTX src code. Pawan ________________________________ From: Santosh [mailto:santosh.ry at gmail.com] Sent: Thursday, January 28, 2010 3:49 PM To: Kharbanda, Pawan Cc: Trent Jarvi; rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat error "./configure: /bin/sh^M: bad interpreter: No such file or directory". I think you need to run dos2unix on script files before compiling. Thanks, Santosh On Thu, Jan 28, 2010 at 5:33 PM, Kharbanda, Pawan > wrote: Trent -- We are upgrading our exisiting OS and JDK on a project that rely heavily on RXTX api's. We are now using JDK1.6 32 bit (build 1.6.0_17-b04) and RedHat 5 on a 64 bit machine. Linux tocrhstg02.dot.state.co.us 2.6.18-164.6.1.el5 #1 SMP Tue Oct 27 11:30:06 EDT 2009 i686 i686 i386 GNU/Linux Red Hat Enterprise Linux Server release 5.4 (Tikanga) I tried to run version 2.1.7 r2 on it but not able to see any of my Digi ports I was able to access only /dev/ttyS0 (physical ports). Not sure if the problem is with the Digi driver or RXTX. I tried to open a Digi port with minicom and it worked fine. I also tried to get latest from CVS (rxtx-devel) and when I do "configure" I see this error "./configure: /bin/sh^M: bad interpreter: No such file or directory". Can someone please help me with this? Thanks for the help. Pawan _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch.txt URL: From juan.vicente.l.g at gmail.com Sat Feb 13 04:44:17 2010 From: juan.vicente.l.g at gmail.com (Juan Vicente Lopez Gutierrez) Date: Sat, 13 Feb 2010 12:44:17 +0100 Subject: [Rxtx] RXTX in macmini OSX 10.5 Message-ID: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> Hello. My name is Juanvi and I'm from Spain. I tried to launch a software created by me in the library CXR java to send information through the serial port and I can not make it work. In windows if I've done but not mac. I have a mac mini with OSX 10.5 and have read in the list of web mail that you CXR if you have managed to make it work on that operating system. I need you help me please. Do I make the mistake that shows me java: run: Stable Library =============================== Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 gnu.io.PortInUseException: Unknow Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:26) at TwoWatSerialComm.main(TwoWaySerialComm.java:106) Experimental: JNI_OnLoad called. GENERACION CORRECTA (total time: 0 seconds) I do not have permission to access the serial port, do not know. Os agradeceria much to sit down. A greeting and thanks. Pardon my English. Juanvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From juan.vicente.l.g at gmail.com Sat Feb 13 14:39:41 2010 From: juan.vicente.l.g at gmail.com (Juan Vicente Lopez Gutierrez) Date: Sat, 13 Feb 2010 22:39:41 +0100 Subject: [Rxtx] Fwd: RXTX in macmini OSX 10.5 In-Reply-To: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> References: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> Message-ID: <29405e5c1002131339m2059d169sdc8549ed9706a1af@mail.gmail.com> ---------- Forwarded message ---------- From: Juan Vicente Lopez Gutierrez Date: 2010/2/13 Subject: RXTX in macmini OSX 10.5 To: rxtx at qbang.org Hello. My name is Juanvi and I'm from Spain. I tried to launch a software created by me in the library CXR java to send information through the serial port and I can not make it work. In windows if I've done but not mac. I have a mac mini with OSX 10.5 and have read in the list of web mail that you CXR if you have managed to make it work on that operating system. I need you help me please. Do I make the mistake that shows me java: run: Stable Library =============================== Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 gnu.io.PortInUseException: Unknow Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:26) at TwoWatSerialComm.main(TwoWaySerialComm.java:106) Experimental: JNI_OnLoad called. GENERACION CORRECTA (total time: 0 seconds) I do not have permission to access the serial port, do not know. Os agradeceria much to sit down. A greeting and thanks. Pardon my English. Juanvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Mon Feb 22 04:35:48 2010 From: george.dma at gmail.com (George H) Date: Mon, 22 Feb 2010 13:35:48 +0200 Subject: [Rxtx] Lingering rxtx process Message-ID: Hi, I am using RXTX v2.1-7. I use it to communicate with 2 serial receipt printers and 1 serial line display device. My program runs well using the RXTX library on Windows and Linux. But... when I installed Linux on another hardware the program does not exit properly. By this I mean that the java program seems to have exited (passed the System.exit(0)) code but the console still does not return to the bash shell. I have to CTRL+C each time to kill the program. And on each restart RXTX has to remove stale LCK files. Just note I am only getting this on one machine, if it makes any difference it is an i686 system with all VIA chipsets and VIA-C7M NannoBGA2 processor. Any ideas? Thanks -- George H george.dma at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Mon Feb 22 04:43:43 2010 From: george.dma at gmail.com (George H) Date: Mon, 22 Feb 2010 13:43:43 +0200 Subject: [Rxtx] Lingering rxtx process Message-ID: Hi, I am using RXTX v2.1-7. I use it to communicate with 2 serial receipt printers and 1 serial line display device. My program runs well using the RXTX library on Windows and Linux. But... when I installed Linux on another hardware the program does not exit properly. By this I mean that the java program seems to have exited (passed the System.exit(0)) code but the console still does not return to the bash shell. I have to CTRL+C each time to kill the program. And on each restart RXTX has to remove stale LCK files. Just note I am only getting this on one machine, if it makes any difference it is an i686 system with all VIA chipsets and VIA-C7M NannoBGA2 processor. Any ideas? Thanks -- George H george.dma at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Tue Feb 23 01:29:42 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Tue, 23 Feb 2010 09:29:42 +0100 Subject: [Rxtx] Lingering rxtx process In-Reply-To: References: Message-ID: <73a89f361002230029w4a9ec14bt56d654e43c1c9623@mail.gmail.com> 2010/2/22 George H > Hi, > > I am using RXTX v2.1-7. > I use it to communicate with 2 serial receipt printers and 1 serial line > display device. My program runs well using the RXTX library on Windows and > Linux. > But... when I installed Linux on another hardware the program does not exit > properly. By this I mean that the java program seems to have exited (passed > the System.exit(0)) code but the console still does not return to the bash > shell. > > Thread in Noember 2009' - http://mailman.qbang.org/pipermail/rxtx/2009-November/5778408.html I have disocvered one technique which solved this problem in Linux Ubuntu and Mac for RXTX pre2.2, but should helps in 2.1.7 as well. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Thu Feb 25 02:41:46 2010 From: george.dma at gmail.com (George H) Date: Thu, 25 Feb 2010 11:41:46 +0200 Subject: [Rxtx] Lingering rxtx process In-Reply-To: <73a89f361002230029w4a9ec14bt56d654e43c1c9623@mail.gmail.com> References: <73a89f361002230029w4a9ec14bt56d654e43c1c9623@mail.gmail.com> Message-ID: With Mariusz Dec help and with the help of the threads that were mentioned http://mailman.qbang.org/pipermail/rxtx/2009-November/5790326.html http://embeddedfreak.wordpress.com/2008/10/08/rxtx-serial-port-helper/ I managed to solved my problem. I didn't really like it so much. I am not using the InputStream.read(byte[], int, int) method as for me I can break out of reading the stream if I get a '\n' or a 0x00. Either way the below code sample works for me. int data = 0; int len = 0; while(true) { data = commReader.getInputStream().read(); if(data == -1 || data == 0x00 || data == '\n' || commReader.getInputStream().available() < 1) { break; } if(len == buffer.length) { processData(buffer); clearBuffer(); } buffer[len++] = (byte)data; } Before I would loop the while until data != -1. But that blocks on .close() and my program never gets to exit. Adding .available() < 1 as a break condition fixes it when I call .close() I am going to see if this is a linux kernel configuration issue or not cos it isn't so obvious and I hardly ever use .available() when reading streams. Love the project though :) -- George H george.dma at gmail.com On Tue, Feb 23, 2010 at 10:29 AM, Mariusz Dec wrote: > > > 2010/2/22 George H > > Hi, >> >> I am using RXTX v2.1-7. >> I use it to communicate with 2 serial receipt printers and 1 serial line >> display device. My program runs well using the RXTX library on Windows and >> Linux. >> But... when I installed Linux on another hardware the program does not >> exit properly. By this I mean that the java program seems to have exited >> (passed the System.exit(0)) code but the console still does not return to >> the bash shell. >> >> Thread in Noember 2009' - > > http://mailman.qbang.org/pipermail/rxtx/2009-November/5778408.html > > I have disocvered one technique which solved this problem in Linux Ubuntu > and Mac for RXTX pre2.2, but should helps in 2.1.7 as well. > > Regards > Mariusz > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 01:02:21 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 13:32:21 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> My serial port driver(apparently) does not support receive timeout.I registered an event listener for DATA_AVAILABLE. However, the control never seems to come out of the 'while' loop.Shouldn't the InputStream.read return a '-1' immediately if no data is available (this seems to be the default operation)? This was tried on a x86 Linux desktop using rxtx-2.1-7 I've added the snippet for clarity: /******************************************************************************************************************************************************************************/ mySerialPort.enableReceiveThreshold(2000);//Trying to set a time limit for read calls System.out.println(mySerialPort.isReceiveTimeoutEnabled()); // I get FALSE, so its not supported on hardware. mySerialPort.addEventListener(this); mySerialPort.notifyOnDataAvailable(true);//register a event with //my SerialEvent listener implementation: public void serialEvent(SerialPortEvent arg0) { int newData=0; switch(arg0.getEventType()){ case SerialPortEvent.DATA_AVAILABLE: while (newData != -1) { try { newData = is.read();//This should eventually return a -1 if no data is available within a timeout.PROBLEM!! System.out.println("Got a byte from port:"+newData); if (newData == -1) { break; } } catch (IOException ex) { System.err.println(ex); return; } } break; } return; } /******************************************************************************************************************************************************************************/ Thanks and regards, Ravi From michael.erskine at ketech.com Wed Feb 3 02:26:50 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 09:26:50 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From michael.erskine at ketech.com Wed Feb 3 05:03:30 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 12:03:30 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > Michael Erskine > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > > Your event handler should handle the event and return immediately so that its > controlling thread can handle other events. I recommend a single read in the > following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) > reads all available bytes up to the size of the buffer returning the number of > bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } After posting this I considered the glaring possibility of the rawbuf read buffer being too small to receive all the available bytes and perhaps skipping data: after all, I'm guessing that is why we see so many posts asking for help with blocking implementations of read event handlers looping on "while(bytes are available)". I've spent this morning writing an extensive multi-threaded unit test suite that includes tests with a tiny buffer compared to the amount of data available and found that no data was being skipped. I now want to know why! The SerialPortEvent.DATA_AVAILABLE event must be being fired again if there is more data available on the input stream. If that is the case then it should be heavily documented with good examples in the wiki to avoid the types of developer anguish we see so regularly. BTW: I'm not at liberty to post the JUnit tests as they use my company's unit test suite framework. Regards, Michael Erskine. From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 06:18:04 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 18:48:04 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Hello Michael, I tried out your suggestion but the problem is that the read(rawbuf) blocks until the entire length of the rawbuf array has been read (blocking). I cannot decide on a reasonable size of the array because it varies from 2 bytes to as much as 50 byes (i'm communicating with a modem,each response is of a different length), which is why i wanted to use non blocking calls. But on a side note, read(byte[]) in turn calls the read() in a loop.In the native C function, the read is supposed to return a -1 upon timeout.But my driver does not support timeout.The default timeout value is zero and the linux select call upon zero time out causes an infinite wait.What am i missing...... Thanks and regards, Ravi Date: Wed, 3 Feb 2010 09:26:50 +0000 From: Michael Erskine To: "rxtx at qbang.org" Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: Content-Type: text/plain; charset="us-ascii" > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From m.kirkland at comcast.net Wed Feb 3 06:46:03 2010 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 3 Feb 2010 05:46:03 -0800 Subject: [Rxtx] One port blocking another port In-Reply-To: References: Message-ID: <68768633814F4D7D86761D34F0764FE0@bengal.net> It turns out this is caused by having the RTS/CTS flow control turned on and me not providing a true on the RTS pin. Somehow it seems the port timing out on a read allows the write to proceed. This is not an issue for my application but I wonder if the write should not proceed until the RTS pin is true even if a read times out. mk -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Monday, January 25, 2010 7:48 PM To: Mike Kirkland Cc: rxtx at qbang.org Subject: Re: [Rxtx] One port blocking another port On Mon, 25 Jan 2010, Mike Kirkland wrote: > > Hi All, > > ? > > I have a program that reads from one com port and writes to another com > port. It also does the same thing in reverse (reads from the second com port > and writes to the first one. It basically ties two com ports together. > > ? > > One port is very chatty and has a consent stream of data. The other port has > very little data. > > ? > > Both ports use a 5000 ms (5 second) time out. > > ? > > The issue I am having is that is appears that the first port?s write to the > second port is blocked while the second port is waiting for input. The first > port?s write proceeds only after the second port has timed out. > > ? > > I suppose I could have something twisted around in my code but I was > wondering if this is a know issue? > Hi Kirk, I've not seen a report like this. Perhaps some simple reproduction code will reveal a problem on your end or help us identify a problem in rxtx. I think there are several users doing multiport communication. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Wed Feb 3 07:03:58 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:03:58 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Message-ID: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> 2010/2/3 Ravishankar N > Hello Michael, > [..] > But on a side note, read(byte[]) in turn calls the read() in a loop.In the > native C function, the read is supposed to return a -1 upon timeout.But my > driver > does not support timeout.The default timeout value is zero and the linux > select call upon zero time out causes an infinite wait.What am i > missing...... > > When I have tested RXTX between platforms, I have observed "hangup" inside JNI driver when no data in Linux, is normal thing. Solution was setting the timeout for RXTX when no data from JNI driver. Something like that: commPort.enableReceiveTimeout(10); And it works perfect.... The only difference is that I am NOT using events - I am using continous read in separate thread and if data is available, is parsed and transferred to application using exception. Regards Mariusz > Thanks and regards, > Ravi > > Date: Wed, 3 Feb 2010 09:26:50 +0000 > From: Michael Erskine > To: "rxtx at qbang.org" > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > Message-ID: > > > Content-Type: text/plain; charset="us-ascii" > > > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of > > Ravishankar N > > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > > > My serial port driver(apparently) does not support receive timeout.I > > registered an event listener for DATA_AVAILABLE. However, the control > never > > seems to come out of the 'while' loop.Shouldn't the > > InputStream.read return a '-1' immediately if no data is available (this > seems > > to be the default operation)? > > Your event handler should handle the event and return immediately so that > its controlling thread can handle other events. I recommend a single read in > the following manner: rawbuf is a byte[] of "reasonable" size and the > read(byte[]) reads all available bytes up to the size of the buffer > returning the number of bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } > > This style of reading has worked for me with RXTX on Linux and Windows XP > for a good few years now in railway industry communications systems. Any > timeouts (largely unnecessary in my applications) can be handled elsewhere, > usually at a higher layer. > > Regards, > Michael Erskine. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Feb 3 07:22:55 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 3 Feb 2010 09:22:55 -0500 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: I'm guessing that this is driver specific. I recently had to support a select()/poll() infrastructure for a linux serial DD, its certainly non trivial to support async IO, so I suspect the problem in this case has to do with missing poll infrastructure in the device driver. This also has to coupled with special open flags for the device (which is within the rxtx code) The key routines within a 2.6 kernel linux device driver are shown below (if you have access to it for your particular device) are indicated below (here is a snippet from my device driver c code that supports polling/select). User space code to test this shown below also, note that the device needs to be opened with the O_NONBLOCK option to support the select/poll api // device driver code ..... /* * File operations supported by this driver. */ static struct file_operations iop_fops = { .owner = THIS_MODULE, .check_flags= iop_check_flags, .ioctl = iop_ioctl, .open = iop_open, .poll = iop_poll, // SUPPORT FOR SELECT/POLL infrastructure .read = iop_read, .release = iop_release, .write = iop_write, }; /** * Select/poll/epoll infrastructure. * * @param file * @param wait * * @return */ static unsigned int iop_poll(struct file *filp, poll_table *wait) { struct iop_device *devp = (struct iop_device *)filp->private_data; // the poll_table wait arg is an opaque pointer poll_wait(filp, &devp->readq, wait); // return from poll indicating whether we have read/write data unsigned int mask = 0; if (kfifo_len(devp->rx_fifo)) { mask |= (POLLIN | POLLRDNORM); } // @JC We don't do select on write yet // if (kfifo_len(devp->tx_fifo)) { // mask |= (POLLOUT | POLLWRNORM); // } // Only print out while debugging // if (mask != 0) { // printk (KERN_INFO "%s: [%04x]\n", __FUNCTION__, mask); // } return mask; } /** * device driver blocking and non blocking read function. This * function reads the requested number of bytes from the read * kfifo blocking as required. * * @param filp * @param buf * @param count * @param f_pos * * @return */ static ssize_t iop_read(struct file *filp, char __user *buf, size_t count, loff_t * ppos) { // access appropriate device struct struct iop_device *devp = (struct iop_device *) filp->private_data; ssize_t retval; // support non blocking mode (default) by checking if the kfifo is empty first if ((kfifo_len(devp->rx_fifo)==0) && (filp->f_flags & O_NONBLOCK)) { return -EAGAIN; } // wait for rx_fifo to receive data via receive interrupts retval = wait_event_interruptible(devp->readq, kfifo_len(devp->rx_fifo) != 0); // check for some error condition if (retval) { printk (KERN_ERR "%s: wait_event_interruptible returned[%d]\n", __FUNCTION__, retval); return retval; } // copy max requested bytes from rx_fifo to device buffer // this may still leave bytes in the kfifo for a subsequent read // if we are reading in a loop retval = kfifo_get(devp->rx_fifo, devp->rxbuf, count); // printk (KERN_INFO "%s: [%d] byte(s)\n", __FUNCTION__, retval); if (copy_to_user(buf, devp->rxbuf, retval)) { printk (KERN_ERR "%s: problem copying rx_fifo data to user buffer\n", __FUNCTION__); return -EFAULT; } return retval; } // a selection of my user space code reading via select()/poll()..... // user space open code iop_fd = ::open( deviceName.data(), O_RDWR | O_NONBLOCK); while ((bytes_to_expect - bytes_read) > 0) { // must reinitialize these between select calls fd_set readfds; FD_ZERO( &readfds ); FD_SET( iop_fd, &readfds ); // 1s sec read polling timeout struct timeval timeout; timeout.tv_sec = 1; timeout.tv_usec = 0; int rc = select( FD_SETSIZE, &readfds, NULL, NULL, &timeout ); // read from file when descriptor // indicates data available without blocking if ((rc > 0) && FD_ISSET(iop_fd, &readfds)) { // read into the appropriate offset within the rx_buf int temp = read(iop_fd, rx_buf + bytes_read, bytes_to_expect - bytes_read); if (!temp) { printf("EOF detected with %d bytes expected\n", bytes_to_expect - bytes_read); } else { bytes_read += temp; } } else if (rc < 0){ printf("%s: select on [%s], bytes_read[%d], errno=%d\n", __FUNCTION__, thread_args->device, bytes_read, errno); } else { printf("%s: select on [%s], bytes_read[%d], timeout\n", __FUNCTION__, thread_args->device, bytes_read); } } On Wed, Feb 3, 2010 at 9:03 AM, Mariusz Dec wrote: > > > 2010/2/3 Ravishankar N > >> Hello Michael, >> [..] >> >> But on a side note, read(byte[]) in turn calls the read() in a loop.In the >> native C function, the read is supposed to return a -1 upon timeout.But my >> driver >> does not support timeout.The default timeout value is zero and the linux >> select call upon zero time out causes an infinite wait.What am i >> missing...... >> >> > When I have tested RXTX between platforms, I have observed "hangup" inside > JNI driver when no data in Linux, is normal thing. > > Solution was setting the timeout for RXTX when no data from JNI driver. > > Something like that: > > commPort.enableReceiveTimeout(10); > > And it works perfect.... > > The only difference is that I am NOT using events - I am using continous > read in separate thread and if data is available, is parsed and transferred > to application using exception. > > Regards > Mariusz > > > >> Thanks and regards, >> Ravi >> >> Date: Wed, 3 Feb 2010 09:26:50 +0000 >> From: Michael Erskine >> To: "rxtx at qbang.org" >> Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? >> Message-ID: >> >> >> Content-Type: text/plain; charset="us-ascii" >> >> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >> Of >> > Ravishankar N >> > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? >> > >> > My serial port driver(apparently) does not support receive timeout.I >> > registered an event listener for DATA_AVAILABLE. However, the control >> never >> > seems to come out of the 'while' loop.Shouldn't the >> > InputStream.read return a '-1' immediately if no data is available (this >> seems >> > to be the default operation)? >> >> Your event handler should handle the event and return immediately so that >> its controlling thread can handle other events. I recommend a single read in >> the following manner: rawbuf is a byte[] of "reasonable" size and the >> read(byte[]) reads all available bytes up to the size of the buffer >> returning the number of bytes actually read... >> >> case SerialPortEvent.DATA_AVAILABLE: >> try { >> int i = is.read(rawbuf); >> if (i == -1) { >> << process EOF condition - should never happen >> >> return; >> } >> << process bytes (rawbuf, i); >> >> return; >> } catch (IOException e) { >> << promptly deal with exception >> >> return; >> } >> >> This style of reading has worked for me with RXTX on Linux and Windows XP >> for a good few years now in railway industry communications systems. Any >> timeouts (largely unnecessary in my applications) can be handled elsewhere, >> usually at a higher layer. >> >> Regards, >> Michael Erskine. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Feb 3 07:33:27 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:33:27 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: <73a89f361002030633j682610afia48dc7accd8e049b@mail.gmail.com> 2010/2/3 John Coffey > I'm guessing that this is driver specific. I recently had to support a > select()/poll() infrastructure for a linux serial DD, its certainly non > trivial to support async IO, so I suspect the problem in this case has to do > with missing poll infrastructure in the device driver. This also has to > coupled with special open flags for the device (which is within the rxtx > code) > > Yes, you are right, it may be driver specific, but in my case I haven't changed blocking JNI driver. I have added ONLY one call to RXTX method mentioned in my previous post and blocking (as seen as from Java app) gone out... Maybe this is not elegant, but works without problem in my app. I am using only FTDI chips and their drivers from couple of years and maybe this is the kind of the way to have no many problems with serial as well? Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From andyrxtx at g0poy.co.uk Wed Feb 3 11:09:04 2010 From: andyrxtx at g0poy.co.uk (andyrxtx at g0poy.co.uk) Date: Wed, 3 Feb 2010 18:09:04 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes Message-ID: <20100203180904.164f24dd@workstation.site> ?Hello RXTX group, I have just joined this group, and this is my first posting. I wanted to pass on some information regarding rxtx, so apologies if this has been brought up before. I have searched back through the archives but nothing specific came up. I am not a Java programmer, and I only came across rxtx a few days ago. I use a piece of test equipment called a miniVNA http://www.miniradiosolutions.com/ This is a serial USB controlled instrument, and it has control software available for MS windows, and a very old and now non-working Linux application. A few days ago Dietmar, DL2SBA released a Java application to control the miniVNA, obviously this application makes use of rxtx. The program worked fine on Windows, so I set about installing it onto Linux. I use SUSE11.1 After a few false starts, I got the system running fairly easily, sorting out the file locking by adding the uucp group to the users account as suggested (I used the 2.2pre binary files) I then passed the install instructions onto another miniVNA user, who also uses SUSE, but he ran into problems. To cut a long story short, he was also having file lock problems, but the uucp fix did not work. Digging into his system I found that there have been some changes in SUSE 11.2. tty ports are now assigned to the dialout group rather than uucp. A hint in the rxtx INSTALL file, suggested that var/lock needs to be checked, so: SUSE 11.1, var/lock is root:uucp SUSE 11.2 var/lock is root:root A search on Google brought up several comments regarding this, and also a bugzilla entry. https://bugzilla.novell.com/show_bug.cgi?id=552095 However from reading the various posts, some of which are in the bugzilla entry, it appears that many distros may be, or have changed to this configuration, and this will undoubtedly break several things, rxtx included. I solved my fellow SUSE users problem by compiling the rxtx libs with the no lock file option during configure, and that solved his problem. As this issue will probably take some time to get resolved across all the various Linux distros, it might be worth considering changing the default on the Linux build of rxtx not to use lockfiles, or provide the two versions of the lib in the binary archive. Thanks for your indulgence Andy From damorales at gmail.com Wed Feb 3 11:33:23 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 15:33:23 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203180904.164f24dd@workstation.site> References: <20100203180904.164f24dd@workstation.site> Message-ID: Hi I had the same problem in Mandriva 2010 and yes, adding the user to the uucp group did not work as it used to be in earlier versions of linux distros, causing RXTX to not work as non root user. The problem appears because the existense of UDEV, now you MUST add a RULE so the group (uucp or whatever) have access (Read, Write, Execute) to the Serial Port. To solve the problem, without needing to recompile RXTX, you must add a rule to grant permissions (0666) to the group for the device or port (tty*, ttyUSB*, etc). I do not remember now what is the line i added but when i come back home i will give it to you (i am at work now). Greetings ! 2010/2/3 > Hello RXTX group, > > I have just joined this group, and this is my first posting. > I wanted to pass on some information regarding rxtx, so apologies if > this has been brought up before. I have searched back through the > archives but nothing specific came up. > > I am not a Java programmer, and I only came across rxtx a few days ago. > > I use a piece of test equipment called a miniVNA > http://www.miniradiosolutions.com/ > > This is a serial USB controlled instrument, and it has control software > available for MS windows, and a very old and now non-working Linux > application. > > A few days ago Dietmar, DL2SBA released a Java application to control the > miniVNA, obviously this application makes use of rxtx. > > The program worked fine on Windows, so I set about installing it onto > Linux. I use SUSE11.1 After a few false starts, I got the system running > fairly easily, sorting out the file locking by adding the uucp group to > the users account as suggested (I used the 2.2pre binary files) I then > passed the install instructions onto another miniVNA user, who also uses > SUSE, but he ran into problems. To cut a long story short, he was > also having file lock problems, but the uucp fix did not work. Digging > into his system I found that there have been some changes in SUSE 11.2. > > tty ports are now assigned to the dialout group rather than uucp. > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > checked, so: > > SUSE 11.1, var/lock is root:uucp > SUSE 11.2 var/lock is root:root > > A search on Google brought up several comments regarding this, and also > a bugzilla entry. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > However from reading the various posts, some of which are in the bugzilla > entry, it appears that many distros may be, or have changed to this > configuration, and this will undoubtedly break several things, rxtx > included. > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > no lock file option during configure, and that solved his problem. > > As this issue will probably take some time to get resolved across all the > various Linux distros, it might be worth considering changing the default > on the Linux build of rxtx not to use lockfiles, or provide the two > versions of the lib in the binary archive. > > Thanks for your indulgence > > Andy > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Wed Feb 3 12:07:02 2010 From: andy at g0poy.com (Andy Eskelson) Date: Wed, 3 Feb 2010 19:07:02 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> Message-ID: <20100203190702.1b0e7015@workstation.site> Thanks Daniel, I am aware of the permissions problem, I have had a udev rules to solve this for other programs for some time. . I don't think that this is the same problem. as far as I can understand things, the lock files are written in var/lock. Previously var/lock and dev/tty-whatever were the same group. Now with var/lock owned by and with a group of root:root anything other than root cannot create a lock file. Even minicom is broken by this change. This change is going to have quite a few knock-on effects I think. Andy On Wed, 3 Feb 2010 15:33:23 -0300 Daniel Morales Salas wrote: > Hi > > I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > group did not work as it used to be in earlier versions of linux distros, > causing RXTX to not work as non root user. > > The problem appears because the existense of UDEV, now you MUST add a RULE > so the group (uucp or whatever) have access (Read, Write, Execute) to the > Serial Port. > > To solve the problem, without needing to recompile RXTX, you must add a rule > to grant permissions (0666) to the group for the device or port (tty*, > ttyUSB*, etc). I do not remember now what is the line i added but when i > come back home i will give it to you (i am at work now). > > Greetings ! > > 2010/2/3 > > > Hello RXTX group, > > > > I have just joined this group, and this is my first posting. > > I wanted to pass on some information regarding rxtx, so apologies if > > this has been brought up before. I have searched back through the > > archives but nothing specific came up. > > > > I am not a Java programmer, and I only came across rxtx a few days ago. > > > > I use a piece of test equipment called a miniVNA > > http://www.miniradiosolutions.com/ > > > > This is a serial USB controlled instrument, and it has control software > > available for MS windows, and a very old and now non-working Linux > > application. > > > > A few days ago Dietmar, DL2SBA released a Java application to control the > > miniVNA, obviously this application makes use of rxtx. > > > > The program worked fine on Windows, so I set about installing it onto > > Linux. I use SUSE11.1 After a few false starts, I got the system running > > fairly easily, sorting out the file locking by adding the uucp group to > > the users account as suggested (I used the 2.2pre binary files) I then > > passed the install instructions onto another miniVNA user, who also uses > > SUSE, but he ran into problems. To cut a long story short, he was > > also having file lock problems, but the uucp fix did not work. Digging > > into his system I found that there have been some changes in SUSE 11.2. > > > > tty ports are now assigned to the dialout group rather than uucp. > > > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > checked, so: > > > > SUSE 11.1, var/lock is root:uucp > > SUSE 11.2 var/lock is root:root > > > > A search on Google brought up several comments regarding this, and also > > a bugzilla entry. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > However from reading the various posts, some of which are in the bugzilla > > entry, it appears that many distros may be, or have changed to this > > configuration, and this will undoubtedly break several things, rxtx > > included. > > > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > > no lock file option during configure, and that solved his problem. > > > > As this issue will probably take some time to get resolved across all the > > various Linux distros, it might be worth considering changing the default > > on the Linux build of rxtx not to use lockfiles, or provide the two > > versions of the lib in the binary archive. > > > > Thanks for your indulgence > > > > Andy > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From thisdyingdream at gmail.com Wed Feb 3 12:32:35 2010 From: thisdyingdream at gmail.com (Steven Harms) Date: Wed, 3 Feb 2010 14:32:35 -0500 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203190702.1b0e7015@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: This is currently a bug in OpenSUSE that affects more than just rxtx, and is a result of unified udev rules. You can work around this by making udev change the group back to uucp until something more happens. https://bugzilla.novell.com/show_bug.cgi?id=552095 Thanks, Steve On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > Thanks Daniel, > > I am aware of the permissions problem, I have had a udev rules to solve > this for other programs for some time. > . > I don't think that this is the same problem. as far as I can understand > things, the lock files are written in var/lock. Previously var/lock and > dev/tty-whatever were the same group. Now with var/lock owned by and with > a group of root:root anything other than root cannot create a lock > file. Even minicom is broken by this change. > > This change is going to have quite a few knock-on effects I think. > > > Andy > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > Daniel Morales Salas wrote: > >> Hi >> >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp >> group did not work as it used to be in earlier versions of linux distros, >> causing RXTX to not work as non root user. >> >> The problem appears because the existense of UDEV, now you MUST add a RULE >> so the group (uucp or whatever) have access (Read, Write, Execute) to the >> Serial Port. >> >> To solve the problem, without needing to recompile RXTX, you must add a rule >> to grant permissions (0666) to the group for the device or port (tty*, >> ttyUSB*, etc). I do not remember now what is the line i added but when i >> come back home i will give it to you (i am at work now). >> >> Greetings ! >> >> 2010/2/3 >> >> > Hello RXTX group, >> > >> > I have just joined this group, and this is my first posting. >> > I wanted to pass on ?some information regarding rxtx, so apologies if >> > this has been brought up before. I have searched back through the >> > archives but nothing specific came up. >> > >> > I am not a Java programmer, and I only came across rxtx a few days ago. >> > >> > I use a piece of test equipment called a miniVNA >> > http://www.miniradiosolutions.com/ >> > >> > This is a serial USB controlled instrument, and it has control software >> > available for MS windows, and a very old and now non-working Linux >> > application. >> > >> > A few days ago Dietmar, DL2SBA released a Java application to control the >> > miniVNA, obviously this application makes use of rxtx. >> > >> > The program worked fine on Windows, so I set about installing it onto >> > Linux. I use SUSE11.1 After a few false starts, I got the system running >> > fairly easily, sorting out the file locking by adding the uucp group to >> > the users account as suggested (I used the 2.2pre binary files) I then >> > passed the install instructions onto another miniVNA user, who also uses >> > SUSE, but he ran into problems. To cut a long story short, he was >> > also having file lock problems, but the uucp fix did not work. Digging >> > into his system I found that there have been some changes in SUSE 11.2. >> > >> > tty ports are now assigned to the dialout group rather than uucp. >> > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be >> > checked, so: >> > >> > SUSE 11.1, var/lock is root:uucp >> > SUSE 11.2 var/lock is root:root >> > >> > A search on Google brought up several comments regarding this, and also >> > a ?bugzilla entry. >> > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 >> > >> > However from reading the various posts, some of which are in the bugzilla >> > entry, it appears that many distros may be, or have changed to this >> > configuration, and this will undoubtedly break several things, rxtx >> > included. >> > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the >> > no lock file option during configure, and that solved his problem. >> > >> > As this issue will probably take some time to get resolved across all the >> > various Linux distros, it might be worth considering changing the default >> > on the Linux build of rxtx not to use lockfiles, or provide the two >> > versions of the lib in the binary archive. >> > >> > Thanks for your indulgence >> > >> > Andy >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> >> >> >> -- >> Atte: >> Daniel Dario Morales Salas >> Ingeniero Civil en Computaci?n e Inform?tica >> Tel?fono: 02 684 3417 >> Celular: 09 643 1802 >> Santiago, Chile > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 WWW: http://www.sharms.org/blog From andy at g0poy.com Wed Feb 3 17:58:29 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 00:58:29 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: <20100204005829.7dc944e1@workstation.site> Thanks Steve, changing the serial ports back the uucp is not a big problem. I have a udev rule that can be easily modified already. However I cannot see any way of dealing with the var/lock problem apart from making it writable to all. Any thoughts? Andy On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms wrote: > This is currently a bug in OpenSUSE that affects more than just rxtx, > and is a result of unified udev rules. You can work around this by > making udev change the group back to uucp until something more > happens. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > Thanks, > > Steve > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > Thanks Daniel, > > > > I am aware of the permissions problem, I have had a udev rules to solve > > this for other programs for some time. > > . > > I don't think that this is the same problem. as far as I can understand > > things, the lock files are written in var/lock. Previously var/lock and > > dev/tty-whatever were the same group. Now with var/lock owned by and with > > a group of root:root anything other than root cannot create a lock > > file. Even minicom is broken by this change. > > > > This change is going to have quite a few knock-on effects I think. > > > > > > Andy > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > Daniel Morales Salas wrote: > > > >> Hi > >> > >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > >> group did not work as it used to be in earlier versions of linux distros, > >> causing RXTX to not work as non root user. > >> > >> The problem appears because the existense of UDEV, now you MUST add a RULE > >> so the group (uucp or whatever) have access (Read, Write, Execute) to the > >> Serial Port. > >> > >> To solve the problem, without needing to recompile RXTX, you must add a rule > >> to grant permissions (0666) to the group for the device or port (tty*, > >> ttyUSB*, etc). I do not remember now what is the line i added but when i > >> come back home i will give it to you (i am at work now). > >> > >> Greetings ! > >> > >> 2010/2/3 > >> > >> > Hello RXTX group, > >> > > >> > I have just joined this group, and this is my first posting. > >> > I wanted to pass on ?some information regarding rxtx, so apologies if > >> > this has been brought up before. I have searched back through the > >> > archives but nothing specific came up. > >> > > >> > I am not a Java programmer, and I only came across rxtx a few days ago. > >> > > >> > I use a piece of test equipment called a miniVNA > >> > http://www.miniradiosolutions.com/ > >> > > >> > This is a serial USB controlled instrument, and it has control software > >> > available for MS windows, and a very old and now non-working Linux > >> > application. > >> > > >> > A few days ago Dietmar, DL2SBA released a Java application to control the > >> > miniVNA, obviously this application makes use of rxtx. > >> > > >> > The program worked fine on Windows, so I set about installing it onto > >> > Linux. I use SUSE11.1 After a few false starts, I got the system running > >> > fairly easily, sorting out the file locking by adding the uucp group to > >> > the users account as suggested (I used the 2.2pre binary files) I then > >> > passed the install instructions onto another miniVNA user, who also uses > >> > SUSE, but he ran into problems. To cut a long story short, he was > >> > also having file lock problems, but the uucp fix did not work. Digging > >> > into his system I found that there have been some changes in SUSE 11.2. > >> > > >> > tty ports are now assigned to the dialout group rather than uucp. > >> > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > >> > checked, so: > >> > > >> > SUSE 11.1, var/lock is root:uucp > >> > SUSE 11.2 var/lock is root:root > >> > > >> > A search on Google brought up several comments regarding this, and also > >> > a ?bugzilla entry. > >> > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > >> > > >> > However from reading the various posts, some of which are in the bugzilla > >> > entry, it appears that many distros may be, or have changed to this > >> > configuration, and this will undoubtedly break several things, rxtx > >> > included. > >> > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the > >> > no lock file option during configure, and that solved his problem. > >> > > >> > As this issue will probably take some time to get resolved across all the > >> > various Linux distros, it might be worth considering changing the default > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > >> > versions of the lib in the binary archive. > >> > > >> > Thanks for your indulgence > >> > > >> > Andy > >> > > >> > _______________________________________________ > >> > Rxtx mailing list > >> > Rxtx at qbang.org > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > >> > >> > >> > >> -- > >> Atte: > >> Daniel Dario Morales Salas > >> Ingeniero Civil en Computaci?n e Inform?tica > >> Tel?fono: 02 684 3417 > >> Celular: 09 643 1802 > >> Santiago, Chile > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > WWW: http://www.sharms.org/blog From damorales at gmail.com Wed Feb 3 18:26:38 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 22:26:38 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100204005829.7dc944e1@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: Hello I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva 2010 this is what i get: drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ and i don't have ANY problem with lock files and RXTX in my java software. All i had to do was add this rule to udev: # serial KERNEL=="tty*", GROUP="uucp", MODE="0666" and that was all. Of course my user (metalklesk) is part of uucp group. I did not make /var/lock writable to all users. Greetings ! 2010/2/3 Andy Eskelson > Thanks Steve, > > changing the serial ports back the uucp is not a big problem. I have a > udev rule that can be easily modified already. However I cannot see any > way of dealing with the var/lock problem apart from making it writable to > all. Any thoughts? > > Andy > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > wrote: > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > and is a result of unified udev rules. You can work around this by > > making udev change the group back to uucp until something more > > happens. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > Thanks, > > > > Steve > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > Thanks Daniel, > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > this for other programs for some time. > > > . > > > I don't think that this is the same problem. as far as I can understand > > > things, the lock files are written in var/lock. Previously var/lock and > > > dev/tty-whatever were the same group. Now with var/lock owned by and > with > > > a group of root:root anything other than root cannot create a lock > > > file. Even minicom is broken by this change. > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > Daniel Morales Salas wrote: > > > > > >> Hi > > >> > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > the uucp > > >> group did not work as it used to be in earlier versions of linux > distros, > > >> causing RXTX to not work as non root user. > > >> > > >> The problem appears because the existense of UDEV, now you MUST add a > RULE > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > the > > >> Serial Port. > > >> > > >> To solve the problem, without needing to recompile RXTX, you must add > a rule > > >> to grant permissions (0666) to the group for the device or port (tty*, > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > i > > >> come back home i will give it to you (i am at work now). > > >> > > >> Greetings ! > > >> > > >> 2010/2/3 > > >> > > >> > Hello RXTX group, > > >> > > > >> > I have just joined this group, and this is my first posting. > > >> > I wanted to pass on some information regarding rxtx, so apologies > if > > >> > this has been brought up before. I have searched back through the > > >> > archives but nothing specific came up. > > >> > > > >> > I am not a Java programmer, and I only came across rxtx a few days > ago. > > >> > > > >> > I use a piece of test equipment called a miniVNA > > >> > http://www.miniradiosolutions.com/ > > >> > > > >> > This is a serial USB controlled instrument, and it has control > software > > >> > available for MS windows, and a very old and now non-working Linux > > >> > application. > > >> > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > control the > > >> > miniVNA, obviously this application makes use of rxtx. > > >> > > > >> > The program worked fine on Windows, so I set about installing it > onto > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > running > > >> > fairly easily, sorting out the file locking by adding the uucp group > to > > >> > the users account as suggested (I used the 2.2pre binary files) I > then > > >> > passed the install instructions onto another miniVNA user, who also > uses > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > >> > also having file lock problems, but the uucp fix did not work. > Digging > > >> > into his system I found that there have been some changes in SUSE > 11.2. > > >> > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > >> > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > >> > checked, so: > > >> > > > >> > SUSE 11.1, var/lock is root:uucp > > >> > SUSE 11.2 var/lock is root:root > > >> > > > >> > A search on Google brought up several comments regarding this, and > also > > >> > a bugzilla entry. > > >> > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > >> > > > >> > However from reading the various posts, some of which are in the > bugzilla > > >> > entry, it appears that many distros may be, or have changed to this > > >> > configuration, and this will undoubtedly break several things, rxtx > > >> > included. > > >> > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > with the > > >> > no lock file option during configure, and that solved his problem. > > >> > > > >> > As this issue will probably take some time to get resolved across > all the > > >> > various Linux distros, it might be worth considering changing the > default > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > >> > versions of the lib in the binary archive. > > >> > > > >> > Thanks for your indulgence > > >> > > > >> > Andy > > >> > > > >> > _______________________________________________ > > >> > Rxtx mailing list > > >> > Rxtx at qbang.org > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > >> > > > >> > > >> > > >> > > >> -- > > >> Atte: > > >> Daniel Dario Morales Salas > > >> Ingeniero Civil en Computaci?n e Inform?tica > > >> Tel?fono: 02 684 3417 > > >> Celular: 09 643 1802 > > >> Santiago, Chile > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at qbang.org > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > -- > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > WWW: http://www.sharms.org/blog > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Thu Feb 4 05:31:46 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 12:31:46 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: <20100204123146.6cffeb67@workstation.site> Thank's for the confirmation. Something odd is going on somewhere in SUSE 11.2. I'll have to build up a local SUSE11.2 system to see if I can nail down exactly what is going on. Something is blocking the lockfiles in var/lock. The net is nice, but it's a bit difficult trying to work out what is going on what the machine in question is in Germany and I'm in the UK :-) Andy On Wed, 3 Feb 2010 22:26:38 -0300 Daniel Morales Salas wrote: > Hello > > I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva > 2010 this is what i get: > > drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ > > and i don't have ANY problem with lock files and RXTX in my java software. > All i had to do was add this rule to udev: > > # serial > KERNEL=="tty*", GROUP="uucp", MODE="0666" > > and that was all. Of course my user (metalklesk) is part of uucp group. > I did not make /var/lock writable to all users. > > Greetings ! > > 2010/2/3 Andy Eskelson > > > Thanks Steve, > > > > changing the serial ports back the uucp is not a big problem. I have a > > udev rule that can be easily modified already. However I cannot see any > > way of dealing with the var/lock problem apart from making it writable to > > all. Any thoughts? > > > > Andy > > > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > > wrote: > > > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > > and is a result of unified udev rules. You can work around this by > > > making udev change the group back to uucp until something more > > > happens. > > > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > > > Thanks, > > > > > > Steve > > > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > > Thanks Daniel, > > > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > > this for other programs for some time. > > > > . > > > > I don't think that this is the same problem. as far as I can understand > > > > things, the lock files are written in var/lock. Previously var/lock and > > > > dev/tty-whatever were the same group. Now with var/lock owned by and > > with > > > > a group of root:root anything other than root cannot create a lock > > > > file. Even minicom is broken by this change. > > > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > > Daniel Morales Salas wrote: > > > > > > > >> Hi > > > >> > > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > > the uucp > > > >> group did not work as it used to be in earlier versions of linux > > distros, > > > >> causing RXTX to not work as non root user. > > > >> > > > >> The problem appears because the existense of UDEV, now you MUST add a > > RULE > > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > > the > > > >> Serial Port. > > > >> > > > >> To solve the problem, without needing to recompile RXTX, you must add > > a rule > > > >> to grant permissions (0666) to the group for the device or port (tty*, > > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > > i > > > >> come back home i will give it to you (i am at work now). > > > >> > > > >> Greetings ! > > > >> > > > >> 2010/2/3 > > > >> > > > >> > Hello RXTX group, > > > >> > > > > >> > I have just joined this group, and this is my first posting. > > > >> > I wanted to pass on some information regarding rxtx, so apologies > > if > > > >> > this has been brought up before. I have searched back through the > > > >> > archives but nothing specific came up. > > > >> > > > > >> > I am not a Java programmer, and I only came across rxtx a few days > > ago. > > > >> > > > > >> > I use a piece of test equipment called a miniVNA > > > >> > http://www.miniradiosolutions.com/ > > > >> > > > > >> > This is a serial USB controlled instrument, and it has control > > software > > > >> > available for MS windows, and a very old and now non-working Linux > > > >> > application. > > > >> > > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > > control the > > > >> > miniVNA, obviously this application makes use of rxtx. > > > >> > > > > >> > The program worked fine on Windows, so I set about installing it > > onto > > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > > running > > > >> > fairly easily, sorting out the file locking by adding the uucp group > > to > > > >> > the users account as suggested (I used the 2.2pre binary files) I > > then > > > >> > passed the install instructions onto another miniVNA user, who also > > uses > > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > > >> > also having file lock problems, but the uucp fix did not work. > > Digging > > > >> > into his system I found that there have been some changes in SUSE > > 11.2. > > > >> > > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > > >> > > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > > >> > checked, so: > > > >> > > > > >> > SUSE 11.1, var/lock is root:uucp > > > >> > SUSE 11.2 var/lock is root:root > > > >> > > > > >> > A search on Google brought up several comments regarding this, and > > also > > > >> > a bugzilla entry. > > > >> > > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > >> > > > > >> > However from reading the various posts, some of which are in the > > bugzilla > > > >> > entry, it appears that many distros may be, or have changed to this > > > >> > configuration, and this will undoubtedly break several things, rxtx > > > >> > included. > > > >> > > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > > with the > > > >> > no lock file option during configure, and that solved his problem. > > > >> > > > > >> > As this issue will probably take some time to get resolved across > > all the > > > >> > various Linux distros, it might be worth considering changing the > > default > > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > > >> > versions of the lib in the binary archive. > > > >> > > > > >> > Thanks for your indulgence > > > >> > > > > >> > Andy > > > >> > > > > >> > _______________________________________________ > > > >> > Rxtx mailing list > > > >> > Rxtx at qbang.org > > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > > >> > > > > >> > > > >> > > > >> > > > >> -- > > > >> Atte: > > > >> Daniel Dario Morales Salas > > > >> Ingeniero Civil en Computaci?n e Inform?tica > > > >> Tel?fono: 02 684 3417 > > > >> Celular: 09 643 1802 > > > >> Santiago, Chile > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at qbang.org > > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > > > -- > > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > > > WWW: http://www.sharms.org/blog > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From Bob_Jacobsen at lbl.gov Thu Feb 4 09:26:49 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Thu, 4 Feb 2010 08:26:49 -0800 Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 Message-ID: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're using RXTX-2.2pre2, although it emits the known message about "Version mismatch". WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 After the usual messing around, we've got it working on 11 Windows versions, multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ have things working rarely say so, so I don't know whether anybody has gotten it to work on 10.4 or not. The problem encountered is this: dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib dyld: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib followed by the JVM crashing hard. I've got those dump files if that would help. Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If so, is there a patch I can get and build? Thanks Bob -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From tjarvi at qbang.org Thu Feb 4 14:22:21 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 4 Feb 2010 14:22:21 -0700 (MST) Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 In-Reply-To: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> References: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> Message-ID: On Thu, 4 Feb 2010, Bob Jacobsen wrote: > We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're > using RXTX-2.2pre2, although it emits the known message about "Version > mismatch". > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > > After the usual messing around, we've got it working on 11 Windows versions, > multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with > a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ > have things working rarely say so, so I don't know whether anybody has gotten > it to work on 10.4 or not. > > The problem encountered is this: > > dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > dyld: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > followed by the JVM crashing hard. I've got those dump files if that would > help. > > Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If > so, is there a patch I can get and build? > Hi Bob, I talked to a coworker about the problem you ran into. It appears that it is possible to target 'older' Mac systems through makefile configuration changes. "Configuring a Makefile-Based Project If you have a makefile-based project, you can also take advantage of SDK-based development, by adding the appropriate options to your compile and link commands. Using SDKs in makefile-based projects requires GCC 4.0 or later. To choose an SDK, you use the -isysroot option with the compiler and the -syslibroot option with the linker. Both options require that you specify the full path to the desired SDK directory. To set the Deployment OS version in a makefile, use a makefile variable of the form: ENVP= MACOSX_DEPLOYMENT_TARGET=10.4. To use this variable in your makefile, include it in front of your compile and link commands." http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html Or build on the oldest system you want to support. -- Trent Jarvi tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Thu Feb 4 14:56:19 2010 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Thu, 4 Feb 2010 14:56:19 -0700 Subject: [Rxtx] RXTX on 64 Bit Redhat In-Reply-To: References: <4ec9eab61001281448g3dd84910r867619948a4e0d7a@mail.gmail.com> Message-ID: Trent -- Finally fixed all my build related issues. I ran into another issue. On one of my machines my JDK is returning multiple folders for the "java.ext.dirs" (java.ext.dirs -> /opt/jdk1.6.0_17/jre/lib/ext:/usr/java/packages/lib/ext) system property. As a result my JVM wasn't able to detect the gnu.io.rxtx.properties. I am attaching a patch for RXTXCommDriver.java file to check for multiple locations. Also i have to assign permission 660 to all my dev ports to be located by RXTX. Pawan ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 5:12 PM To: Trent Jarvi Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Here is the error i get when i build the src from release-2-1-7 -bash-3.2$ make ( \ \ cd i686-pc-linux-gnu; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/ jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I/opt/jav a1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec - c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialImp.lo;\ if [ "Serial" = "Serial" ]; then \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I /opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_tim espec -c /home/jb_stg/rxtx/rxtx-devel/./src/fuserImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ else \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo; \ fi; \ ) gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/inclu de -I/opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need _timespec -c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -fPIC -DPIC -o /hom e/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/.libs/SerialImp.o /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:25:29: error: gnu_io_RXTXPort.h: No such file or directory In file included from /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:113: /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:91: error: expected specifier-qua lifier-list before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'jobject' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:408: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:409: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:410: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:411: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:415: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:416: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:417: error: expected '=', ',', '; ', 'asm' or '__attribute__' before 'is_interrupted' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:418: error: expected declaration specifiers or '...' before 'jint' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:424: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:441: error: expected ')' before ' *' token ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 4:57 PM To: Santosh Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Santosh -- Thank you. That fixed the issue. All -- What CVS branch or release should i use to get the latest RXTX src code. Pawan ________________________________ From: Santosh [mailto:santosh.ry at gmail.com] Sent: Thursday, January 28, 2010 3:49 PM To: Kharbanda, Pawan Cc: Trent Jarvi; rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat error "./configure: /bin/sh^M: bad interpreter: No such file or directory". I think you need to run dos2unix on script files before compiling. Thanks, Santosh On Thu, Jan 28, 2010 at 5:33 PM, Kharbanda, Pawan > wrote: Trent -- We are upgrading our exisiting OS and JDK on a project that rely heavily on RXTX api's. We are now using JDK1.6 32 bit (build 1.6.0_17-b04) and RedHat 5 on a 64 bit machine. Linux tocrhstg02.dot.state.co.us 2.6.18-164.6.1.el5 #1 SMP Tue Oct 27 11:30:06 EDT 2009 i686 i686 i386 GNU/Linux Red Hat Enterprise Linux Server release 5.4 (Tikanga) I tried to run version 2.1.7 r2 on it but not able to see any of my Digi ports I was able to access only /dev/ttyS0 (physical ports). Not sure if the problem is with the Digi driver or RXTX. I tried to open a Digi port with minicom and it worked fine. I also tried to get latest from CVS (rxtx-devel) and when I do "configure" I see this error "./configure: /bin/sh^M: bad interpreter: No such file or directory". Can someone please help me with this? Thanks for the help. Pawan _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch.txt URL: From juan.vicente.l.g at gmail.com Sat Feb 13 04:44:17 2010 From: juan.vicente.l.g at gmail.com (Juan Vicente Lopez Gutierrez) Date: Sat, 13 Feb 2010 12:44:17 +0100 Subject: [Rxtx] RXTX in macmini OSX 10.5 Message-ID: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> Hello. My name is Juanvi and I'm from Spain. I tried to launch a software created by me in the library CXR java to send information through the serial port and I can not make it work. In windows if I've done but not mac. I have a mac mini with OSX 10.5 and have read in the list of web mail that you CXR if you have managed to make it work on that operating system. I need you help me please. Do I make the mistake that shows me java: run: Stable Library =============================== Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 gnu.io.PortInUseException: Unknow Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:26) at TwoWatSerialComm.main(TwoWaySerialComm.java:106) Experimental: JNI_OnLoad called. GENERACION CORRECTA (total time: 0 seconds) I do not have permission to access the serial port, do not know. Os agradeceria much to sit down. A greeting and thanks. Pardon my English. Juanvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From juan.vicente.l.g at gmail.com Sat Feb 13 14:39:41 2010 From: juan.vicente.l.g at gmail.com (Juan Vicente Lopez Gutierrez) Date: Sat, 13 Feb 2010 22:39:41 +0100 Subject: [Rxtx] Fwd: RXTX in macmini OSX 10.5 In-Reply-To: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> References: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> Message-ID: <29405e5c1002131339m2059d169sdc8549ed9706a1af@mail.gmail.com> ---------- Forwarded message ---------- From: Juan Vicente Lopez Gutierrez Date: 2010/2/13 Subject: RXTX in macmini OSX 10.5 To: rxtx at qbang.org Hello. My name is Juanvi and I'm from Spain. I tried to launch a software created by me in the library CXR java to send information through the serial port and I can not make it work. In windows if I've done but not mac. I have a mac mini with OSX 10.5 and have read in the list of web mail that you CXR if you have managed to make it work on that operating system. I need you help me please. Do I make the mistake that shows me java: run: Stable Library =============================== Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 gnu.io.PortInUseException: Unknow Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:26) at TwoWatSerialComm.main(TwoWaySerialComm.java:106) Experimental: JNI_OnLoad called. GENERACION CORRECTA (total time: 0 seconds) I do not have permission to access the serial port, do not know. Os agradeceria much to sit down. A greeting and thanks. Pardon my English. Juanvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Mon Feb 22 04:35:48 2010 From: george.dma at gmail.com (George H) Date: Mon, 22 Feb 2010 13:35:48 +0200 Subject: [Rxtx] Lingering rxtx process Message-ID: Hi, I am using RXTX v2.1-7. I use it to communicate with 2 serial receipt printers and 1 serial line display device. My program runs well using the RXTX library on Windows and Linux. But... when I installed Linux on another hardware the program does not exit properly. By this I mean that the java program seems to have exited (passed the System.exit(0)) code but the console still does not return to the bash shell. I have to CTRL+C each time to kill the program. And on each restart RXTX has to remove stale LCK files. Just note I am only getting this on one machine, if it makes any difference it is an i686 system with all VIA chipsets and VIA-C7M NannoBGA2 processor. Any ideas? Thanks -- George H george.dma at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Mon Feb 22 04:43:43 2010 From: george.dma at gmail.com (George H) Date: Mon, 22 Feb 2010 13:43:43 +0200 Subject: [Rxtx] Lingering rxtx process Message-ID: Hi, I am using RXTX v2.1-7. I use it to communicate with 2 serial receipt printers and 1 serial line display device. My program runs well using the RXTX library on Windows and Linux. But... when I installed Linux on another hardware the program does not exit properly. By this I mean that the java program seems to have exited (passed the System.exit(0)) code but the console still does not return to the bash shell. I have to CTRL+C each time to kill the program. And on each restart RXTX has to remove stale LCK files. Just note I am only getting this on one machine, if it makes any difference it is an i686 system with all VIA chipsets and VIA-C7M NannoBGA2 processor. Any ideas? Thanks -- George H george.dma at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Tue Feb 23 01:29:42 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Tue, 23 Feb 2010 09:29:42 +0100 Subject: [Rxtx] Lingering rxtx process In-Reply-To: References: Message-ID: <73a89f361002230029w4a9ec14bt56d654e43c1c9623@mail.gmail.com> 2010/2/22 George H > Hi, > > I am using RXTX v2.1-7. > I use it to communicate with 2 serial receipt printers and 1 serial line > display device. My program runs well using the RXTX library on Windows and > Linux. > But... when I installed Linux on another hardware the program does not exit > properly. By this I mean that the java program seems to have exited (passed > the System.exit(0)) code but the console still does not return to the bash > shell. > > Thread in Noember 2009' - http://mailman.qbang.org/pipermail/rxtx/2009-November/5778408.html I have disocvered one technique which solved this problem in Linux Ubuntu and Mac for RXTX pre2.2, but should helps in 2.1.7 as well. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Thu Feb 25 02:41:46 2010 From: george.dma at gmail.com (George H) Date: Thu, 25 Feb 2010 11:41:46 +0200 Subject: [Rxtx] Lingering rxtx process In-Reply-To: <73a89f361002230029w4a9ec14bt56d654e43c1c9623@mail.gmail.com> References: <73a89f361002230029w4a9ec14bt56d654e43c1c9623@mail.gmail.com> Message-ID: With Mariusz Dec help and with the help of the threads that were mentioned http://mailman.qbang.org/pipermail/rxtx/2009-November/5790326.html http://embeddedfreak.wordpress.com/2008/10/08/rxtx-serial-port-helper/ I managed to solved my problem. I didn't really like it so much. I am not using the InputStream.read(byte[], int, int) method as for me I can break out of reading the stream if I get a '\n' or a 0x00. Either way the below code sample works for me. int data = 0; int len = 0; while(true) { data = commReader.getInputStream().read(); if(data == -1 || data == 0x00 || data == '\n' || commReader.getInputStream().available() < 1) { break; } if(len == buffer.length) { processData(buffer); clearBuffer(); } buffer[len++] = (byte)data; } Before I would loop the while until data != -1. But that blocks on .close() and my program never gets to exit. Adding .available() < 1 as a break condition fixes it when I call .close() I am going to see if this is a linux kernel configuration issue or not cos it isn't so obvious and I hardly ever use .available() when reading streams. Love the project though :) -- George H george.dma at gmail.com On Tue, Feb 23, 2010 at 10:29 AM, Mariusz Dec wrote: > > > 2010/2/22 George H > > Hi, >> >> I am using RXTX v2.1-7. >> I use it to communicate with 2 serial receipt printers and 1 serial line >> display device. My program runs well using the RXTX library on Windows and >> Linux. >> But... when I installed Linux on another hardware the program does not >> exit properly. By this I mean that the java program seems to have exited >> (passed the System.exit(0)) code but the console still does not return to >> the bash shell. >> >> Thread in Noember 2009' - > > http://mailman.qbang.org/pipermail/rxtx/2009-November/5778408.html > > I have disocvered one technique which solved this problem in Linux Ubuntu > and Mac for RXTX pre2.2, but should helps in 2.1.7 as well. > > Regards > Mariusz > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 01:02:21 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 13:32:21 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> My serial port driver(apparently) does not support receive timeout.I registered an event listener for DATA_AVAILABLE. However, the control never seems to come out of the 'while' loop.Shouldn't the InputStream.read return a '-1' immediately if no data is available (this seems to be the default operation)? This was tried on a x86 Linux desktop using rxtx-2.1-7 I've added the snippet for clarity: /******************************************************************************************************************************************************************************/ mySerialPort.enableReceiveThreshold(2000);//Trying to set a time limit for read calls System.out.println(mySerialPort.isReceiveTimeoutEnabled()); // I get FALSE, so its not supported on hardware. mySerialPort.addEventListener(this); mySerialPort.notifyOnDataAvailable(true);//register a event with //my SerialEvent listener implementation: public void serialEvent(SerialPortEvent arg0) { int newData=0; switch(arg0.getEventType()){ case SerialPortEvent.DATA_AVAILABLE: while (newData != -1) { try { newData = is.read();//This should eventually return a -1 if no data is available within a timeout.PROBLEM!! System.out.println("Got a byte from port:"+newData); if (newData == -1) { break; } } catch (IOException ex) { System.err.println(ex); return; } } break; } return; } /******************************************************************************************************************************************************************************/ Thanks and regards, Ravi From michael.erskine at ketech.com Wed Feb 3 02:26:50 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 09:26:50 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From michael.erskine at ketech.com Wed Feb 3 05:03:30 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 12:03:30 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > Michael Erskine > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > > Your event handler should handle the event and return immediately so that its > controlling thread can handle other events. I recommend a single read in the > following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) > reads all available bytes up to the size of the buffer returning the number of > bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } After posting this I considered the glaring possibility of the rawbuf read buffer being too small to receive all the available bytes and perhaps skipping data: after all, I'm guessing that is why we see so many posts asking for help with blocking implementations of read event handlers looping on "while(bytes are available)". I've spent this morning writing an extensive multi-threaded unit test suite that includes tests with a tiny buffer compared to the amount of data available and found that no data was being skipped. I now want to know why! The SerialPortEvent.DATA_AVAILABLE event must be being fired again if there is more data available on the input stream. If that is the case then it should be heavily documented with good examples in the wiki to avoid the types of developer anguish we see so regularly. BTW: I'm not at liberty to post the JUnit tests as they use my company's unit test suite framework. Regards, Michael Erskine. From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 06:18:04 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 18:48:04 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Hello Michael, I tried out your suggestion but the problem is that the read(rawbuf) blocks until the entire length of the rawbuf array has been read (blocking). I cannot decide on a reasonable size of the array because it varies from 2 bytes to as much as 50 byes (i'm communicating with a modem,each response is of a different length), which is why i wanted to use non blocking calls. But on a side note, read(byte[]) in turn calls the read() in a loop.In the native C function, the read is supposed to return a -1 upon timeout.But my driver does not support timeout.The default timeout value is zero and the linux select call upon zero time out causes an infinite wait.What am i missing...... Thanks and regards, Ravi Date: Wed, 3 Feb 2010 09:26:50 +0000 From: Michael Erskine To: "rxtx at qbang.org" Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: Content-Type: text/plain; charset="us-ascii" > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From m.kirkland at comcast.net Wed Feb 3 06:46:03 2010 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 3 Feb 2010 05:46:03 -0800 Subject: [Rxtx] One port blocking another port In-Reply-To: References: Message-ID: <68768633814F4D7D86761D34F0764FE0@bengal.net> It turns out this is caused by having the RTS/CTS flow control turned on and me not providing a true on the RTS pin. Somehow it seems the port timing out on a read allows the write to proceed. This is not an issue for my application but I wonder if the write should not proceed until the RTS pin is true even if a read times out. mk -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Monday, January 25, 2010 7:48 PM To: Mike Kirkland Cc: rxtx at qbang.org Subject: Re: [Rxtx] One port blocking another port On Mon, 25 Jan 2010, Mike Kirkland wrote: > > Hi All, > > ? > > I have a program that reads from one com port and writes to another com > port. It also does the same thing in reverse (reads from the second com port > and writes to the first one. It basically ties two com ports together. > > ? > > One port is very chatty and has a consent stream of data. The other port has > very little data. > > ? > > Both ports use a 5000 ms (5 second) time out. > > ? > > The issue I am having is that is appears that the first port?s write to the > second port is blocked while the second port is waiting for input. The first > port?s write proceeds only after the second port has timed out. > > ? > > I suppose I could have something twisted around in my code but I was > wondering if this is a know issue? > Hi Kirk, I've not seen a report like this. Perhaps some simple reproduction code will reveal a problem on your end or help us identify a problem in rxtx. I think there are several users doing multiport communication. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Wed Feb 3 07:03:58 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:03:58 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Message-ID: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> 2010/2/3 Ravishankar N > Hello Michael, > [..] > But on a side note, read(byte[]) in turn calls the read() in a loop.In the > native C function, the read is supposed to return a -1 upon timeout.But my > driver > does not support timeout.The default timeout value is zero and the linux > select call upon zero time out causes an infinite wait.What am i > missing...... > > When I have tested RXTX between platforms, I have observed "hangup" inside JNI driver when no data in Linux, is normal thing. Solution was setting the timeout for RXTX when no data from JNI driver. Something like that: commPort.enableReceiveTimeout(10); And it works perfect.... The only difference is that I am NOT using events - I am using continous read in separate thread and if data is available, is parsed and transferred to application using exception. Regards Mariusz > Thanks and regards, > Ravi > > Date: Wed, 3 Feb 2010 09:26:50 +0000 > From: Michael Erskine > To: "rxtx at qbang.org" > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > Message-ID: > > > Content-Type: text/plain; charset="us-ascii" > > > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of > > Ravishankar N > > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > > > My serial port driver(apparently) does not support receive timeout.I > > registered an event listener for DATA_AVAILABLE. However, the control > never > > seems to come out of the 'while' loop.Shouldn't the > > InputStream.read return a '-1' immediately if no data is available (this > seems > > to be the default operation)? > > Your event handler should handle the event and return immediately so that > its controlling thread can handle other events. I recommend a single read in > the following manner: rawbuf is a byte[] of "reasonable" size and the > read(byte[]) reads all available bytes up to the size of the buffer > returning the number of bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } > > This style of reading has worked for me with RXTX on Linux and Windows XP > for a good few years now in railway industry communications systems. Any > timeouts (largely unnecessary in my applications) can be handled elsewhere, > usually at a higher layer. > > Regards, > Michael Erskine. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Feb 3 07:22:55 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 3 Feb 2010 09:22:55 -0500 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: I'm guessing that this is driver specific. I recently had to support a select()/poll() infrastructure for a linux serial DD, its certainly non trivial to support async IO, so I suspect the problem in this case has to do with missing poll infrastructure in the device driver. This also has to coupled with special open flags for the device (which is within the rxtx code) The key routines within a 2.6 kernel linux device driver are shown below (if you have access to it for your particular device) are indicated below (here is a snippet from my device driver c code that supports polling/select). User space code to test this shown below also, note that the device needs to be opened with the O_NONBLOCK option to support the select/poll api // device driver code ..... /* * File operations supported by this driver. */ static struct file_operations iop_fops = { .owner = THIS_MODULE, .check_flags= iop_check_flags, .ioctl = iop_ioctl, .open = iop_open, .poll = iop_poll, // SUPPORT FOR SELECT/POLL infrastructure .read = iop_read, .release = iop_release, .write = iop_write, }; /** * Select/poll/epoll infrastructure. * * @param file * @param wait * * @return */ static unsigned int iop_poll(struct file *filp, poll_table *wait) { struct iop_device *devp = (struct iop_device *)filp->private_data; // the poll_table wait arg is an opaque pointer poll_wait(filp, &devp->readq, wait); // return from poll indicating whether we have read/write data unsigned int mask = 0; if (kfifo_len(devp->rx_fifo)) { mask |= (POLLIN | POLLRDNORM); } // @JC We don't do select on write yet // if (kfifo_len(devp->tx_fifo)) { // mask |= (POLLOUT | POLLWRNORM); // } // Only print out while debugging // if (mask != 0) { // printk (KERN_INFO "%s: [%04x]\n", __FUNCTION__, mask); // } return mask; } /** * device driver blocking and non blocking read function. This * function reads the requested number of bytes from the read * kfifo blocking as required. * * @param filp * @param buf * @param count * @param f_pos * * @return */ static ssize_t iop_read(struct file *filp, char __user *buf, size_t count, loff_t * ppos) { // access appropriate device struct struct iop_device *devp = (struct iop_device *) filp->private_data; ssize_t retval; // support non blocking mode (default) by checking if the kfifo is empty first if ((kfifo_len(devp->rx_fifo)==0) && (filp->f_flags & O_NONBLOCK)) { return -EAGAIN; } // wait for rx_fifo to receive data via receive interrupts retval = wait_event_interruptible(devp->readq, kfifo_len(devp->rx_fifo) != 0); // check for some error condition if (retval) { printk (KERN_ERR "%s: wait_event_interruptible returned[%d]\n", __FUNCTION__, retval); return retval; } // copy max requested bytes from rx_fifo to device buffer // this may still leave bytes in the kfifo for a subsequent read // if we are reading in a loop retval = kfifo_get(devp->rx_fifo, devp->rxbuf, count); // printk (KERN_INFO "%s: [%d] byte(s)\n", __FUNCTION__, retval); if (copy_to_user(buf, devp->rxbuf, retval)) { printk (KERN_ERR "%s: problem copying rx_fifo data to user buffer\n", __FUNCTION__); return -EFAULT; } return retval; } // a selection of my user space code reading via select()/poll()..... // user space open code iop_fd = ::open( deviceName.data(), O_RDWR | O_NONBLOCK); while ((bytes_to_expect - bytes_read) > 0) { // must reinitialize these between select calls fd_set readfds; FD_ZERO( &readfds ); FD_SET( iop_fd, &readfds ); // 1s sec read polling timeout struct timeval timeout; timeout.tv_sec = 1; timeout.tv_usec = 0; int rc = select( FD_SETSIZE, &readfds, NULL, NULL, &timeout ); // read from file when descriptor // indicates data available without blocking if ((rc > 0) && FD_ISSET(iop_fd, &readfds)) { // read into the appropriate offset within the rx_buf int temp = read(iop_fd, rx_buf + bytes_read, bytes_to_expect - bytes_read); if (!temp) { printf("EOF detected with %d bytes expected\n", bytes_to_expect - bytes_read); } else { bytes_read += temp; } } else if (rc < 0){ printf("%s: select on [%s], bytes_read[%d], errno=%d\n", __FUNCTION__, thread_args->device, bytes_read, errno); } else { printf("%s: select on [%s], bytes_read[%d], timeout\n", __FUNCTION__, thread_args->device, bytes_read); } } On Wed, Feb 3, 2010 at 9:03 AM, Mariusz Dec wrote: > > > 2010/2/3 Ravishankar N > >> Hello Michael, >> [..] >> >> But on a side note, read(byte[]) in turn calls the read() in a loop.In the >> native C function, the read is supposed to return a -1 upon timeout.But my >> driver >> does not support timeout.The default timeout value is zero and the linux >> select call upon zero time out causes an infinite wait.What am i >> missing...... >> >> > When I have tested RXTX between platforms, I have observed "hangup" inside > JNI driver when no data in Linux, is normal thing. > > Solution was setting the timeout for RXTX when no data from JNI driver. > > Something like that: > > commPort.enableReceiveTimeout(10); > > And it works perfect.... > > The only difference is that I am NOT using events - I am using continous > read in separate thread and if data is available, is parsed and transferred > to application using exception. > > Regards > Mariusz > > > >> Thanks and regards, >> Ravi >> >> Date: Wed, 3 Feb 2010 09:26:50 +0000 >> From: Michael Erskine >> To: "rxtx at qbang.org" >> Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? >> Message-ID: >> >> >> Content-Type: text/plain; charset="us-ascii" >> >> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >> Of >> > Ravishankar N >> > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? >> > >> > My serial port driver(apparently) does not support receive timeout.I >> > registered an event listener for DATA_AVAILABLE. However, the control >> never >> > seems to come out of the 'while' loop.Shouldn't the >> > InputStream.read return a '-1' immediately if no data is available (this >> seems >> > to be the default operation)? >> >> Your event handler should handle the event and return immediately so that >> its controlling thread can handle other events. I recommend a single read in >> the following manner: rawbuf is a byte[] of "reasonable" size and the >> read(byte[]) reads all available bytes up to the size of the buffer >> returning the number of bytes actually read... >> >> case SerialPortEvent.DATA_AVAILABLE: >> try { >> int i = is.read(rawbuf); >> if (i == -1) { >> << process EOF condition - should never happen >> >> return; >> } >> << process bytes (rawbuf, i); >> >> return; >> } catch (IOException e) { >> << promptly deal with exception >> >> return; >> } >> >> This style of reading has worked for me with RXTX on Linux and Windows XP >> for a good few years now in railway industry communications systems. Any >> timeouts (largely unnecessary in my applications) can be handled elsewhere, >> usually at a higher layer. >> >> Regards, >> Michael Erskine. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Feb 3 07:33:27 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:33:27 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: <73a89f361002030633j682610afia48dc7accd8e049b@mail.gmail.com> 2010/2/3 John Coffey > I'm guessing that this is driver specific. I recently had to support a > select()/poll() infrastructure for a linux serial DD, its certainly non > trivial to support async IO, so I suspect the problem in this case has to do > with missing poll infrastructure in the device driver. This also has to > coupled with special open flags for the device (which is within the rxtx > code) > > Yes, you are right, it may be driver specific, but in my case I haven't changed blocking JNI driver. I have added ONLY one call to RXTX method mentioned in my previous post and blocking (as seen as from Java app) gone out... Maybe this is not elegant, but works without problem in my app. I am using only FTDI chips and their drivers from couple of years and maybe this is the kind of the way to have no many problems with serial as well? Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From andyrxtx at g0poy.co.uk Wed Feb 3 11:09:04 2010 From: andyrxtx at g0poy.co.uk (andyrxtx at g0poy.co.uk) Date: Wed, 3 Feb 2010 18:09:04 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes Message-ID: <20100203180904.164f24dd@workstation.site> ?Hello RXTX group, I have just joined this group, and this is my first posting. I wanted to pass on some information regarding rxtx, so apologies if this has been brought up before. I have searched back through the archives but nothing specific came up. I am not a Java programmer, and I only came across rxtx a few days ago. I use a piece of test equipment called a miniVNA http://www.miniradiosolutions.com/ This is a serial USB controlled instrument, and it has control software available for MS windows, and a very old and now non-working Linux application. A few days ago Dietmar, DL2SBA released a Java application to control the miniVNA, obviously this application makes use of rxtx. The program worked fine on Windows, so I set about installing it onto Linux. I use SUSE11.1 After a few false starts, I got the system running fairly easily, sorting out the file locking by adding the uucp group to the users account as suggested (I used the 2.2pre binary files) I then passed the install instructions onto another miniVNA user, who also uses SUSE, but he ran into problems. To cut a long story short, he was also having file lock problems, but the uucp fix did not work. Digging into his system I found that there have been some changes in SUSE 11.2. tty ports are now assigned to the dialout group rather than uucp. A hint in the rxtx INSTALL file, suggested that var/lock needs to be checked, so: SUSE 11.1, var/lock is root:uucp SUSE 11.2 var/lock is root:root A search on Google brought up several comments regarding this, and also a bugzilla entry. https://bugzilla.novell.com/show_bug.cgi?id=552095 However from reading the various posts, some of which are in the bugzilla entry, it appears that many distros may be, or have changed to this configuration, and this will undoubtedly break several things, rxtx included. I solved my fellow SUSE users problem by compiling the rxtx libs with the no lock file option during configure, and that solved his problem. As this issue will probably take some time to get resolved across all the various Linux distros, it might be worth considering changing the default on the Linux build of rxtx not to use lockfiles, or provide the two versions of the lib in the binary archive. Thanks for your indulgence Andy From damorales at gmail.com Wed Feb 3 11:33:23 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 15:33:23 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203180904.164f24dd@workstation.site> References: <20100203180904.164f24dd@workstation.site> Message-ID: Hi I had the same problem in Mandriva 2010 and yes, adding the user to the uucp group did not work as it used to be in earlier versions of linux distros, causing RXTX to not work as non root user. The problem appears because the existense of UDEV, now you MUST add a RULE so the group (uucp or whatever) have access (Read, Write, Execute) to the Serial Port. To solve the problem, without needing to recompile RXTX, you must add a rule to grant permissions (0666) to the group for the device or port (tty*, ttyUSB*, etc). I do not remember now what is the line i added but when i come back home i will give it to you (i am at work now). Greetings ! 2010/2/3 > Hello RXTX group, > > I have just joined this group, and this is my first posting. > I wanted to pass on some information regarding rxtx, so apologies if > this has been brought up before. I have searched back through the > archives but nothing specific came up. > > I am not a Java programmer, and I only came across rxtx a few days ago. > > I use a piece of test equipment called a miniVNA > http://www.miniradiosolutions.com/ > > This is a serial USB controlled instrument, and it has control software > available for MS windows, and a very old and now non-working Linux > application. > > A few days ago Dietmar, DL2SBA released a Java application to control the > miniVNA, obviously this application makes use of rxtx. > > The program worked fine on Windows, so I set about installing it onto > Linux. I use SUSE11.1 After a few false starts, I got the system running > fairly easily, sorting out the file locking by adding the uucp group to > the users account as suggested (I used the 2.2pre binary files) I then > passed the install instructions onto another miniVNA user, who also uses > SUSE, but he ran into problems. To cut a long story short, he was > also having file lock problems, but the uucp fix did not work. Digging > into his system I found that there have been some changes in SUSE 11.2. > > tty ports are now assigned to the dialout group rather than uucp. > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > checked, so: > > SUSE 11.1, var/lock is root:uucp > SUSE 11.2 var/lock is root:root > > A search on Google brought up several comments regarding this, and also > a bugzilla entry. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > However from reading the various posts, some of which are in the bugzilla > entry, it appears that many distros may be, or have changed to this > configuration, and this will undoubtedly break several things, rxtx > included. > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > no lock file option during configure, and that solved his problem. > > As this issue will probably take some time to get resolved across all the > various Linux distros, it might be worth considering changing the default > on the Linux build of rxtx not to use lockfiles, or provide the two > versions of the lib in the binary archive. > > Thanks for your indulgence > > Andy > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Wed Feb 3 12:07:02 2010 From: andy at g0poy.com (Andy Eskelson) Date: Wed, 3 Feb 2010 19:07:02 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> Message-ID: <20100203190702.1b0e7015@workstation.site> Thanks Daniel, I am aware of the permissions problem, I have had a udev rules to solve this for other programs for some time. . I don't think that this is the same problem. as far as I can understand things, the lock files are written in var/lock. Previously var/lock and dev/tty-whatever were the same group. Now with var/lock owned by and with a group of root:root anything other than root cannot create a lock file. Even minicom is broken by this change. This change is going to have quite a few knock-on effects I think. Andy On Wed, 3 Feb 2010 15:33:23 -0300 Daniel Morales Salas wrote: > Hi > > I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > group did not work as it used to be in earlier versions of linux distros, > causing RXTX to not work as non root user. > > The problem appears because the existense of UDEV, now you MUST add a RULE > so the group (uucp or whatever) have access (Read, Write, Execute) to the > Serial Port. > > To solve the problem, without needing to recompile RXTX, you must add a rule > to grant permissions (0666) to the group for the device or port (tty*, > ttyUSB*, etc). I do not remember now what is the line i added but when i > come back home i will give it to you (i am at work now). > > Greetings ! > > 2010/2/3 > > > Hello RXTX group, > > > > I have just joined this group, and this is my first posting. > > I wanted to pass on some information regarding rxtx, so apologies if > > this has been brought up before. I have searched back through the > > archives but nothing specific came up. > > > > I am not a Java programmer, and I only came across rxtx a few days ago. > > > > I use a piece of test equipment called a miniVNA > > http://www.miniradiosolutions.com/ > > > > This is a serial USB controlled instrument, and it has control software > > available for MS windows, and a very old and now non-working Linux > > application. > > > > A few days ago Dietmar, DL2SBA released a Java application to control the > > miniVNA, obviously this application makes use of rxtx. > > > > The program worked fine on Windows, so I set about installing it onto > > Linux. I use SUSE11.1 After a few false starts, I got the system running > > fairly easily, sorting out the file locking by adding the uucp group to > > the users account as suggested (I used the 2.2pre binary files) I then > > passed the install instructions onto another miniVNA user, who also uses > > SUSE, but he ran into problems. To cut a long story short, he was > > also having file lock problems, but the uucp fix did not work. Digging > > into his system I found that there have been some changes in SUSE 11.2. > > > > tty ports are now assigned to the dialout group rather than uucp. > > > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > checked, so: > > > > SUSE 11.1, var/lock is root:uucp > > SUSE 11.2 var/lock is root:root > > > > A search on Google brought up several comments regarding this, and also > > a bugzilla entry. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > However from reading the various posts, some of which are in the bugzilla > > entry, it appears that many distros may be, or have changed to this > > configuration, and this will undoubtedly break several things, rxtx > > included. > > > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > > no lock file option during configure, and that solved his problem. > > > > As this issue will probably take some time to get resolved across all the > > various Linux distros, it might be worth considering changing the default > > on the Linux build of rxtx not to use lockfiles, or provide the two > > versions of the lib in the binary archive. > > > > Thanks for your indulgence > > > > Andy > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From thisdyingdream at gmail.com Wed Feb 3 12:32:35 2010 From: thisdyingdream at gmail.com (Steven Harms) Date: Wed, 3 Feb 2010 14:32:35 -0500 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203190702.1b0e7015@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: This is currently a bug in OpenSUSE that affects more than just rxtx, and is a result of unified udev rules. You can work around this by making udev change the group back to uucp until something more happens. https://bugzilla.novell.com/show_bug.cgi?id=552095 Thanks, Steve On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > Thanks Daniel, > > I am aware of the permissions problem, I have had a udev rules to solve > this for other programs for some time. > . > I don't think that this is the same problem. as far as I can understand > things, the lock files are written in var/lock. Previously var/lock and > dev/tty-whatever were the same group. Now with var/lock owned by and with > a group of root:root anything other than root cannot create a lock > file. Even minicom is broken by this change. > > This change is going to have quite a few knock-on effects I think. > > > Andy > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > Daniel Morales Salas wrote: > >> Hi >> >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp >> group did not work as it used to be in earlier versions of linux distros, >> causing RXTX to not work as non root user. >> >> The problem appears because the existense of UDEV, now you MUST add a RULE >> so the group (uucp or whatever) have access (Read, Write, Execute) to the >> Serial Port. >> >> To solve the problem, without needing to recompile RXTX, you must add a rule >> to grant permissions (0666) to the group for the device or port (tty*, >> ttyUSB*, etc). I do not remember now what is the line i added but when i >> come back home i will give it to you (i am at work now). >> >> Greetings ! >> >> 2010/2/3 >> >> > Hello RXTX group, >> > >> > I have just joined this group, and this is my first posting. >> > I wanted to pass on ?some information regarding rxtx, so apologies if >> > this has been brought up before. I have searched back through the >> > archives but nothing specific came up. >> > >> > I am not a Java programmer, and I only came across rxtx a few days ago. >> > >> > I use a piece of test equipment called a miniVNA >> > http://www.miniradiosolutions.com/ >> > >> > This is a serial USB controlled instrument, and it has control software >> > available for MS windows, and a very old and now non-working Linux >> > application. >> > >> > A few days ago Dietmar, DL2SBA released a Java application to control the >> > miniVNA, obviously this application makes use of rxtx. >> > >> > The program worked fine on Windows, so I set about installing it onto >> > Linux. I use SUSE11.1 After a few false starts, I got the system running >> > fairly easily, sorting out the file locking by adding the uucp group to >> > the users account as suggested (I used the 2.2pre binary files) I then >> > passed the install instructions onto another miniVNA user, who also uses >> > SUSE, but he ran into problems. To cut a long story short, he was >> > also having file lock problems, but the uucp fix did not work. Digging >> > into his system I found that there have been some changes in SUSE 11.2. >> > >> > tty ports are now assigned to the dialout group rather than uucp. >> > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be >> > checked, so: >> > >> > SUSE 11.1, var/lock is root:uucp >> > SUSE 11.2 var/lock is root:root >> > >> > A search on Google brought up several comments regarding this, and also >> > a ?bugzilla entry. >> > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 >> > >> > However from reading the various posts, some of which are in the bugzilla >> > entry, it appears that many distros may be, or have changed to this >> > configuration, and this will undoubtedly break several things, rxtx >> > included. >> > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the >> > no lock file option during configure, and that solved his problem. >> > >> > As this issue will probably take some time to get resolved across all the >> > various Linux distros, it might be worth considering changing the default >> > on the Linux build of rxtx not to use lockfiles, or provide the two >> > versions of the lib in the binary archive. >> > >> > Thanks for your indulgence >> > >> > Andy >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> >> >> >> -- >> Atte: >> Daniel Dario Morales Salas >> Ingeniero Civil en Computaci?n e Inform?tica >> Tel?fono: 02 684 3417 >> Celular: 09 643 1802 >> Santiago, Chile > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 WWW: http://www.sharms.org/blog From andy at g0poy.com Wed Feb 3 17:58:29 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 00:58:29 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: <20100204005829.7dc944e1@workstation.site> Thanks Steve, changing the serial ports back the uucp is not a big problem. I have a udev rule that can be easily modified already. However I cannot see any way of dealing with the var/lock problem apart from making it writable to all. Any thoughts? Andy On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms wrote: > This is currently a bug in OpenSUSE that affects more than just rxtx, > and is a result of unified udev rules. You can work around this by > making udev change the group back to uucp until something more > happens. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > Thanks, > > Steve > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > Thanks Daniel, > > > > I am aware of the permissions problem, I have had a udev rules to solve > > this for other programs for some time. > > . > > I don't think that this is the same problem. as far as I can understand > > things, the lock files are written in var/lock. Previously var/lock and > > dev/tty-whatever were the same group. Now with var/lock owned by and with > > a group of root:root anything other than root cannot create a lock > > file. Even minicom is broken by this change. > > > > This change is going to have quite a few knock-on effects I think. > > > > > > Andy > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > Daniel Morales Salas wrote: > > > >> Hi > >> > >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > >> group did not work as it used to be in earlier versions of linux distros, > >> causing RXTX to not work as non root user. > >> > >> The problem appears because the existense of UDEV, now you MUST add a RULE > >> so the group (uucp or whatever) have access (Read, Write, Execute) to the > >> Serial Port. > >> > >> To solve the problem, without needing to recompile RXTX, you must add a rule > >> to grant permissions (0666) to the group for the device or port (tty*, > >> ttyUSB*, etc). I do not remember now what is the line i added but when i > >> come back home i will give it to you (i am at work now). > >> > >> Greetings ! > >> > >> 2010/2/3 > >> > >> > Hello RXTX group, > >> > > >> > I have just joined this group, and this is my first posting. > >> > I wanted to pass on ?some information regarding rxtx, so apologies if > >> > this has been brought up before. I have searched back through the > >> > archives but nothing specific came up. > >> > > >> > I am not a Java programmer, and I only came across rxtx a few days ago. > >> > > >> > I use a piece of test equipment called a miniVNA > >> > http://www.miniradiosolutions.com/ > >> > > >> > This is a serial USB controlled instrument, and it has control software > >> > available for MS windows, and a very old and now non-working Linux > >> > application. > >> > > >> > A few days ago Dietmar, DL2SBA released a Java application to control the > >> > miniVNA, obviously this application makes use of rxtx. > >> > > >> > The program worked fine on Windows, so I set about installing it onto > >> > Linux. I use SUSE11.1 After a few false starts, I got the system running > >> > fairly easily, sorting out the file locking by adding the uucp group to > >> > the users account as suggested (I used the 2.2pre binary files) I then > >> > passed the install instructions onto another miniVNA user, who also uses > >> > SUSE, but he ran into problems. To cut a long story short, he was > >> > also having file lock problems, but the uucp fix did not work. Digging > >> > into his system I found that there have been some changes in SUSE 11.2. > >> > > >> > tty ports are now assigned to the dialout group rather than uucp. > >> > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > >> > checked, so: > >> > > >> > SUSE 11.1, var/lock is root:uucp > >> > SUSE 11.2 var/lock is root:root > >> > > >> > A search on Google brought up several comments regarding this, and also > >> > a ?bugzilla entry. > >> > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > >> > > >> > However from reading the various posts, some of which are in the bugzilla > >> > entry, it appears that many distros may be, or have changed to this > >> > configuration, and this will undoubtedly break several things, rxtx > >> > included. > >> > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the > >> > no lock file option during configure, and that solved his problem. > >> > > >> > As this issue will probably take some time to get resolved across all the > >> > various Linux distros, it might be worth considering changing the default > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > >> > versions of the lib in the binary archive. > >> > > >> > Thanks for your indulgence > >> > > >> > Andy > >> > > >> > _______________________________________________ > >> > Rxtx mailing list > >> > Rxtx at qbang.org > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > >> > >> > >> > >> -- > >> Atte: > >> Daniel Dario Morales Salas > >> Ingeniero Civil en Computaci?n e Inform?tica > >> Tel?fono: 02 684 3417 > >> Celular: 09 643 1802 > >> Santiago, Chile > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > WWW: http://www.sharms.org/blog From damorales at gmail.com Wed Feb 3 18:26:38 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 22:26:38 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100204005829.7dc944e1@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: Hello I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva 2010 this is what i get: drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ and i don't have ANY problem with lock files and RXTX in my java software. All i had to do was add this rule to udev: # serial KERNEL=="tty*", GROUP="uucp", MODE="0666" and that was all. Of course my user (metalklesk) is part of uucp group. I did not make /var/lock writable to all users. Greetings ! 2010/2/3 Andy Eskelson > Thanks Steve, > > changing the serial ports back the uucp is not a big problem. I have a > udev rule that can be easily modified already. However I cannot see any > way of dealing with the var/lock problem apart from making it writable to > all. Any thoughts? > > Andy > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > wrote: > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > and is a result of unified udev rules. You can work around this by > > making udev change the group back to uucp until something more > > happens. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > Thanks, > > > > Steve > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > Thanks Daniel, > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > this for other programs for some time. > > > . > > > I don't think that this is the same problem. as far as I can understand > > > things, the lock files are written in var/lock. Previously var/lock and > > > dev/tty-whatever were the same group. Now with var/lock owned by and > with > > > a group of root:root anything other than root cannot create a lock > > > file. Even minicom is broken by this change. > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > Daniel Morales Salas wrote: > > > > > >> Hi > > >> > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > the uucp > > >> group did not work as it used to be in earlier versions of linux > distros, > > >> causing RXTX to not work as non root user. > > >> > > >> The problem appears because the existense of UDEV, now you MUST add a > RULE > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > the > > >> Serial Port. > > >> > > >> To solve the problem, without needing to recompile RXTX, you must add > a rule > > >> to grant permissions (0666) to the group for the device or port (tty*, > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > i > > >> come back home i will give it to you (i am at work now). > > >> > > >> Greetings ! > > >> > > >> 2010/2/3 > > >> > > >> > Hello RXTX group, > > >> > > > >> > I have just joined this group, and this is my first posting. > > >> > I wanted to pass on some information regarding rxtx, so apologies > if > > >> > this has been brought up before. I have searched back through the > > >> > archives but nothing specific came up. > > >> > > > >> > I am not a Java programmer, and I only came across rxtx a few days > ago. > > >> > > > >> > I use a piece of test equipment called a miniVNA > > >> > http://www.miniradiosolutions.com/ > > >> > > > >> > This is a serial USB controlled instrument, and it has control > software > > >> > available for MS windows, and a very old and now non-working Linux > > >> > application. > > >> > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > control the > > >> > miniVNA, obviously this application makes use of rxtx. > > >> > > > >> > The program worked fine on Windows, so I set about installing it > onto > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > running > > >> > fairly easily, sorting out the file locking by adding the uucp group > to > > >> > the users account as suggested (I used the 2.2pre binary files) I > then > > >> > passed the install instructions onto another miniVNA user, who also > uses > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > >> > also having file lock problems, but the uucp fix did not work. > Digging > > >> > into his system I found that there have been some changes in SUSE > 11.2. > > >> > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > >> > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > >> > checked, so: > > >> > > > >> > SUSE 11.1, var/lock is root:uucp > > >> > SUSE 11.2 var/lock is root:root > > >> > > > >> > A search on Google brought up several comments regarding this, and > also > > >> > a bugzilla entry. > > >> > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > >> > > > >> > However from reading the various posts, some of which are in the > bugzilla > > >> > entry, it appears that many distros may be, or have changed to this > > >> > configuration, and this will undoubtedly break several things, rxtx > > >> > included. > > >> > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > with the > > >> > no lock file option during configure, and that solved his problem. > > >> > > > >> > As this issue will probably take some time to get resolved across > all the > > >> > various Linux distros, it might be worth considering changing the > default > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > >> > versions of the lib in the binary archive. > > >> > > > >> > Thanks for your indulgence > > >> > > > >> > Andy > > >> > > > >> > _______________________________________________ > > >> > Rxtx mailing list > > >> > Rxtx at qbang.org > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > >> > > > >> > > >> > > >> > > >> -- > > >> Atte: > > >> Daniel Dario Morales Salas > > >> Ingeniero Civil en Computaci?n e Inform?tica > > >> Tel?fono: 02 684 3417 > > >> Celular: 09 643 1802 > > >> Santiago, Chile > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at qbang.org > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > -- > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > WWW: http://www.sharms.org/blog > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Thu Feb 4 05:31:46 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 12:31:46 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: <20100204123146.6cffeb67@workstation.site> Thank's for the confirmation. Something odd is going on somewhere in SUSE 11.2. I'll have to build up a local SUSE11.2 system to see if I can nail down exactly what is going on. Something is blocking the lockfiles in var/lock. The net is nice, but it's a bit difficult trying to work out what is going on what the machine in question is in Germany and I'm in the UK :-) Andy On Wed, 3 Feb 2010 22:26:38 -0300 Daniel Morales Salas wrote: > Hello > > I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva > 2010 this is what i get: > > drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ > > and i don't have ANY problem with lock files and RXTX in my java software. > All i had to do was add this rule to udev: > > # serial > KERNEL=="tty*", GROUP="uucp", MODE="0666" > > and that was all. Of course my user (metalklesk) is part of uucp group. > I did not make /var/lock writable to all users. > > Greetings ! > > 2010/2/3 Andy Eskelson > > > Thanks Steve, > > > > changing the serial ports back the uucp is not a big problem. I have a > > udev rule that can be easily modified already. However I cannot see any > > way of dealing with the var/lock problem apart from making it writable to > > all. Any thoughts? > > > > Andy > > > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > > wrote: > > > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > > and is a result of unified udev rules. You can work around this by > > > making udev change the group back to uucp until something more > > > happens. > > > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > > > Thanks, > > > > > > Steve > > > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > > Thanks Daniel, > > > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > > this for other programs for some time. > > > > . > > > > I don't think that this is the same problem. as far as I can understand > > > > things, the lock files are written in var/lock. Previously var/lock and > > > > dev/tty-whatever were the same group. Now with var/lock owned by and > > with > > > > a group of root:root anything other than root cannot create a lock > > > > file. Even minicom is broken by this change. > > > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > > Daniel Morales Salas wrote: > > > > > > > >> Hi > > > >> > > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > > the uucp > > > >> group did not work as it used to be in earlier versions of linux > > distros, > > > >> causing RXTX to not work as non root user. > > > >> > > > >> The problem appears because the existense of UDEV, now you MUST add a > > RULE > > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > > the > > > >> Serial Port. > > > >> > > > >> To solve the problem, without needing to recompile RXTX, you must add > > a rule > > > >> to grant permissions (0666) to the group for the device or port (tty*, > > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > > i > > > >> come back home i will give it to you (i am at work now). > > > >> > > > >> Greetings ! > > > >> > > > >> 2010/2/3 > > > >> > > > >> > Hello RXTX group, > > > >> > > > > >> > I have just joined this group, and this is my first posting. > > > >> > I wanted to pass on some information regarding rxtx, so apologies > > if > > > >> > this has been brought up before. I have searched back through the > > > >> > archives but nothing specific came up. > > > >> > > > > >> > I am not a Java programmer, and I only came across rxtx a few days > > ago. > > > >> > > > > >> > I use a piece of test equipment called a miniVNA > > > >> > http://www.miniradiosolutions.com/ > > > >> > > > > >> > This is a serial USB controlled instrument, and it has control > > software > > > >> > available for MS windows, and a very old and now non-working Linux > > > >> > application. > > > >> > > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > > control the > > > >> > miniVNA, obviously this application makes use of rxtx. > > > >> > > > > >> > The program worked fine on Windows, so I set about installing it > > onto > > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > > running > > > >> > fairly easily, sorting out the file locking by adding the uucp group > > to > > > >> > the users account as suggested (I used the 2.2pre binary files) I > > then > > > >> > passed the install instructions onto another miniVNA user, who also > > uses > > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > > >> > also having file lock problems, but the uucp fix did not work. > > Digging > > > >> > into his system I found that there have been some changes in SUSE > > 11.2. > > > >> > > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > > >> > > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > > >> > checked, so: > > > >> > > > > >> > SUSE 11.1, var/lock is root:uucp > > > >> > SUSE 11.2 var/lock is root:root > > > >> > > > > >> > A search on Google brought up several comments regarding this, and > > also > > > >> > a bugzilla entry. > > > >> > > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > >> > > > > >> > However from reading the various posts, some of which are in the > > bugzilla > > > >> > entry, it appears that many distros may be, or have changed to this > > > >> > configuration, and this will undoubtedly break several things, rxtx > > > >> > included. > > > >> > > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > > with the > > > >> > no lock file option during configure, and that solved his problem. > > > >> > > > > >> > As this issue will probably take some time to get resolved across > > all the > > > >> > various Linux distros, it might be worth considering changing the > > default > > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > > >> > versions of the lib in the binary archive. > > > >> > > > > >> > Thanks for your indulgence > > > >> > > > > >> > Andy > > > >> > > > > >> > _______________________________________________ > > > >> > Rxtx mailing list > > > >> > Rxtx at qbang.org > > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > > >> > > > > >> > > > >> > > > >> > > > >> -- > > > >> Atte: > > > >> Daniel Dario Morales Salas > > > >> Ingeniero Civil en Computaci?n e Inform?tica > > > >> Tel?fono: 02 684 3417 > > > >> Celular: 09 643 1802 > > > >> Santiago, Chile > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at qbang.org > > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > > > -- > > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > > > WWW: http://www.sharms.org/blog > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From Bob_Jacobsen at lbl.gov Thu Feb 4 09:26:49 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Thu, 4 Feb 2010 08:26:49 -0800 Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 Message-ID: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're using RXTX-2.2pre2, although it emits the known message about "Version mismatch". WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 After the usual messing around, we've got it working on 11 Windows versions, multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ have things working rarely say so, so I don't know whether anybody has gotten it to work on 10.4 or not. The problem encountered is this: dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib dyld: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib followed by the JVM crashing hard. I've got those dump files if that would help. Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If so, is there a patch I can get and build? Thanks Bob -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From tjarvi at qbang.org Thu Feb 4 14:22:21 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 4 Feb 2010 14:22:21 -0700 (MST) Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 In-Reply-To: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> References: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> Message-ID: On Thu, 4 Feb 2010, Bob Jacobsen wrote: > We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're > using RXTX-2.2pre2, although it emits the known message about "Version > mismatch". > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > > After the usual messing around, we've got it working on 11 Windows versions, > multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with > a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ > have things working rarely say so, so I don't know whether anybody has gotten > it to work on 10.4 or not. > > The problem encountered is this: > > dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > dyld: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > followed by the JVM crashing hard. I've got those dump files if that would > help. > > Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If > so, is there a patch I can get and build? > Hi Bob, I talked to a coworker about the problem you ran into. It appears that it is possible to target 'older' Mac systems through makefile configuration changes. "Configuring a Makefile-Based Project If you have a makefile-based project, you can also take advantage of SDK-based development, by adding the appropriate options to your compile and link commands. Using SDKs in makefile-based projects requires GCC 4.0 or later. To choose an SDK, you use the -isysroot option with the compiler and the -syslibroot option with the linker. Both options require that you specify the full path to the desired SDK directory. To set the Deployment OS version in a makefile, use a makefile variable of the form: ENVP= MACOSX_DEPLOYMENT_TARGET=10.4. To use this variable in your makefile, include it in front of your compile and link commands." http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html Or build on the oldest system you want to support. -- Trent Jarvi tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Thu Feb 4 14:56:19 2010 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Thu, 4 Feb 2010 14:56:19 -0700 Subject: [Rxtx] RXTX on 64 Bit Redhat In-Reply-To: References: <4ec9eab61001281448g3dd84910r867619948a4e0d7a@mail.gmail.com> Message-ID: Trent -- Finally fixed all my build related issues. I ran into another issue. On one of my machines my JDK is returning multiple folders for the "java.ext.dirs" (java.ext.dirs -> /opt/jdk1.6.0_17/jre/lib/ext:/usr/java/packages/lib/ext) system property. As a result my JVM wasn't able to detect the gnu.io.rxtx.properties. I am attaching a patch for RXTXCommDriver.java file to check for multiple locations. Also i have to assign permission 660 to all my dev ports to be located by RXTX. Pawan ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 5:12 PM To: Trent Jarvi Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Here is the error i get when i build the src from release-2-1-7 -bash-3.2$ make ( \ \ cd i686-pc-linux-gnu; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/ jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I/opt/jav a1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec - c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialImp.lo;\ if [ "Serial" = "Serial" ]; then \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I /opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_tim espec -c /home/jb_stg/rxtx/rxtx-devel/./src/fuserImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ else \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo; \ fi; \ ) gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/inclu de -I/opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need _timespec -c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -fPIC -DPIC -o /hom e/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/.libs/SerialImp.o /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:25:29: error: gnu_io_RXTXPort.h: No such file or directory In file included from /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:113: /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:91: error: expected specifier-qua lifier-list before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'jobject' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:408: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:409: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:410: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:411: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:415: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:416: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:417: error: expected '=', ',', '; ', 'asm' or '__attribute__' before 'is_interrupted' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:418: error: expected declaration specifiers or '...' before 'jint' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:424: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:441: error: expected ')' before ' *' token ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 4:57 PM To: Santosh Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Santosh -- Thank you. That fixed the issue. All -- What CVS branch or release should i use to get the latest RXTX src code. Pawan ________________________________ From: Santosh [mailto:santosh.ry at gmail.com] Sent: Thursday, January 28, 2010 3:49 PM To: Kharbanda, Pawan Cc: Trent Jarvi; rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat error "./configure: /bin/sh^M: bad interpreter: No such file or directory". I think you need to run dos2unix on script files before compiling. Thanks, Santosh On Thu, Jan 28, 2010 at 5:33 PM, Kharbanda, Pawan > wrote: Trent -- We are upgrading our exisiting OS and JDK on a project that rely heavily on RXTX api's. We are now using JDK1.6 32 bit (build 1.6.0_17-b04) and RedHat 5 on a 64 bit machine. Linux tocrhstg02.dot.state.co.us 2.6.18-164.6.1.el5 #1 SMP Tue Oct 27 11:30:06 EDT 2009 i686 i686 i386 GNU/Linux Red Hat Enterprise Linux Server release 5.4 (Tikanga) I tried to run version 2.1.7 r2 on it but not able to see any of my Digi ports I was able to access only /dev/ttyS0 (physical ports). Not sure if the problem is with the Digi driver or RXTX. I tried to open a Digi port with minicom and it worked fine. I also tried to get latest from CVS (rxtx-devel) and when I do "configure" I see this error "./configure: /bin/sh^M: bad interpreter: No such file or directory". Can someone please help me with this? Thanks for the help. Pawan _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch.txt URL: From juan.vicente.l.g at gmail.com Sat Feb 13 04:44:17 2010 From: juan.vicente.l.g at gmail.com (Juan Vicente Lopez Gutierrez) Date: Sat, 13 Feb 2010 12:44:17 +0100 Subject: [Rxtx] RXTX in macmini OSX 10.5 Message-ID: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> Hello. My name is Juanvi and I'm from Spain. I tried to launch a software created by me in the library CXR java to send information through the serial port and I can not make it work. In windows if I've done but not mac. I have a mac mini with OSX 10.5 and have read in the list of web mail that you CXR if you have managed to make it work on that operating system. I need you help me please. Do I make the mistake that shows me java: run: Stable Library =============================== Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 gnu.io.PortInUseException: Unknow Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:26) at TwoWatSerialComm.main(TwoWaySerialComm.java:106) Experimental: JNI_OnLoad called. GENERACION CORRECTA (total time: 0 seconds) I do not have permission to access the serial port, do not know. Os agradeceria much to sit down. A greeting and thanks. Pardon my English. Juanvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From juan.vicente.l.g at gmail.com Sat Feb 13 14:39:41 2010 From: juan.vicente.l.g at gmail.com (Juan Vicente Lopez Gutierrez) Date: Sat, 13 Feb 2010 22:39:41 +0100 Subject: [Rxtx] Fwd: RXTX in macmini OSX 10.5 In-Reply-To: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> References: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> Message-ID: <29405e5c1002131339m2059d169sdc8549ed9706a1af@mail.gmail.com> ---------- Forwarded message ---------- From: Juan Vicente Lopez Gutierrez Date: 2010/2/13 Subject: RXTX in macmini OSX 10.5 To: rxtx at qbang.org Hello. My name is Juanvi and I'm from Spain. I tried to launch a software created by me in the library CXR java to send information through the serial port and I can not make it work. In windows if I've done but not mac. I have a mac mini with OSX 10.5 and have read in the list of web mail that you CXR if you have managed to make it work on that operating system. I need you help me please. Do I make the mistake that shows me java: run: Stable Library =============================== Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 gnu.io.PortInUseException: Unknow Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:26) at TwoWatSerialComm.main(TwoWaySerialComm.java:106) Experimental: JNI_OnLoad called. GENERACION CORRECTA (total time: 0 seconds) I do not have permission to access the serial port, do not know. Os agradeceria much to sit down. A greeting and thanks. Pardon my English. Juanvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Mon Feb 22 04:35:48 2010 From: george.dma at gmail.com (George H) Date: Mon, 22 Feb 2010 13:35:48 +0200 Subject: [Rxtx] Lingering rxtx process Message-ID: Hi, I am using RXTX v2.1-7. I use it to communicate with 2 serial receipt printers and 1 serial line display device. My program runs well using the RXTX library on Windows and Linux. But... when I installed Linux on another hardware the program does not exit properly. By this I mean that the java program seems to have exited (passed the System.exit(0)) code but the console still does not return to the bash shell. I have to CTRL+C each time to kill the program. And on each restart RXTX has to remove stale LCK files. Just note I am only getting this on one machine, if it makes any difference it is an i686 system with all VIA chipsets and VIA-C7M NannoBGA2 processor. Any ideas? Thanks -- George H george.dma at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Mon Feb 22 04:43:43 2010 From: george.dma at gmail.com (George H) Date: Mon, 22 Feb 2010 13:43:43 +0200 Subject: [Rxtx] Lingering rxtx process Message-ID: Hi, I am using RXTX v2.1-7. I use it to communicate with 2 serial receipt printers and 1 serial line display device. My program runs well using the RXTX library on Windows and Linux. But... when I installed Linux on another hardware the program does not exit properly. By this I mean that the java program seems to have exited (passed the System.exit(0)) code but the console still does not return to the bash shell. I have to CTRL+C each time to kill the program. And on each restart RXTX has to remove stale LCK files. Just note I am only getting this on one machine, if it makes any difference it is an i686 system with all VIA chipsets and VIA-C7M NannoBGA2 processor. Any ideas? Thanks -- George H george.dma at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Tue Feb 23 01:29:42 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Tue, 23 Feb 2010 09:29:42 +0100 Subject: [Rxtx] Lingering rxtx process In-Reply-To: References: Message-ID: <73a89f361002230029w4a9ec14bt56d654e43c1c9623@mail.gmail.com> 2010/2/22 George H > Hi, > > I am using RXTX v2.1-7. > I use it to communicate with 2 serial receipt printers and 1 serial line > display device. My program runs well using the RXTX library on Windows and > Linux. > But... when I installed Linux on another hardware the program does not exit > properly. By this I mean that the java program seems to have exited (passed > the System.exit(0)) code but the console still does not return to the bash > shell. > > Thread in Noember 2009' - http://mailman.qbang.org/pipermail/rxtx/2009-November/5778408.html I have disocvered one technique which solved this problem in Linux Ubuntu and Mac for RXTX pre2.2, but should helps in 2.1.7 as well. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Thu Feb 25 02:41:46 2010 From: george.dma at gmail.com (George H) Date: Thu, 25 Feb 2010 11:41:46 +0200 Subject: [Rxtx] Lingering rxtx process In-Reply-To: <73a89f361002230029w4a9ec14bt56d654e43c1c9623@mail.gmail.com> References: <73a89f361002230029w4a9ec14bt56d654e43c1c9623@mail.gmail.com> Message-ID: With Mariusz Dec help and with the help of the threads that were mentioned http://mailman.qbang.org/pipermail/rxtx/2009-November/5790326.html http://embeddedfreak.wordpress.com/2008/10/08/rxtx-serial-port-helper/ I managed to solved my problem. I didn't really like it so much. I am not using the InputStream.read(byte[], int, int) method as for me I can break out of reading the stream if I get a '\n' or a 0x00. Either way the below code sample works for me. int data = 0; int len = 0; while(true) { data = commReader.getInputStream().read(); if(data == -1 || data == 0x00 || data == '\n' || commReader.getInputStream().available() < 1) { break; } if(len == buffer.length) { processData(buffer); clearBuffer(); } buffer[len++] = (byte)data; } Before I would loop the while until data != -1. But that blocks on .close() and my program never gets to exit. Adding .available() < 1 as a break condition fixes it when I call .close() I am going to see if this is a linux kernel configuration issue or not cos it isn't so obvious and I hardly ever use .available() when reading streams. Love the project though :) -- George H george.dma at gmail.com On Tue, Feb 23, 2010 at 10:29 AM, Mariusz Dec wrote: > > > 2010/2/22 George H > > Hi, >> >> I am using RXTX v2.1-7. >> I use it to communicate with 2 serial receipt printers and 1 serial line >> display device. My program runs well using the RXTX library on Windows and >> Linux. >> But... when I installed Linux on another hardware the program does not >> exit properly. By this I mean that the java program seems to have exited >> (passed the System.exit(0)) code but the console still does not return to >> the bash shell. >> >> Thread in Noember 2009' - > > http://mailman.qbang.org/pipermail/rxtx/2009-November/5778408.html > > I have disocvered one technique which solved this problem in Linux Ubuntu > and Mac for RXTX pre2.2, but should helps in 2.1.7 as well. > > Regards > Mariusz > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 01:02:21 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 13:32:21 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> My serial port driver(apparently) does not support receive timeout.I registered an event listener for DATA_AVAILABLE. However, the control never seems to come out of the 'while' loop.Shouldn't the InputStream.read return a '-1' immediately if no data is available (this seems to be the default operation)? This was tried on a x86 Linux desktop using rxtx-2.1-7 I've added the snippet for clarity: /******************************************************************************************************************************************************************************/ mySerialPort.enableReceiveThreshold(2000);//Trying to set a time limit for read calls System.out.println(mySerialPort.isReceiveTimeoutEnabled()); // I get FALSE, so its not supported on hardware. mySerialPort.addEventListener(this); mySerialPort.notifyOnDataAvailable(true);//register a event with //my SerialEvent listener implementation: public void serialEvent(SerialPortEvent arg0) { int newData=0; switch(arg0.getEventType()){ case SerialPortEvent.DATA_AVAILABLE: while (newData != -1) { try { newData = is.read();//This should eventually return a -1 if no data is available within a timeout.PROBLEM!! System.out.println("Got a byte from port:"+newData); if (newData == -1) { break; } } catch (IOException ex) { System.err.println(ex); return; } } break; } return; } /******************************************************************************************************************************************************************************/ Thanks and regards, Ravi From michael.erskine at ketech.com Wed Feb 3 02:26:50 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 09:26:50 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From michael.erskine at ketech.com Wed Feb 3 05:03:30 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 12:03:30 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > Michael Erskine > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > > Your event handler should handle the event and return immediately so that its > controlling thread can handle other events. I recommend a single read in the > following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) > reads all available bytes up to the size of the buffer returning the number of > bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } After posting this I considered the glaring possibility of the rawbuf read buffer being too small to receive all the available bytes and perhaps skipping data: after all, I'm guessing that is why we see so many posts asking for help with blocking implementations of read event handlers looping on "while(bytes are available)". I've spent this morning writing an extensive multi-threaded unit test suite that includes tests with a tiny buffer compared to the amount of data available and found that no data was being skipped. I now want to know why! The SerialPortEvent.DATA_AVAILABLE event must be being fired again if there is more data available on the input stream. If that is the case then it should be heavily documented with good examples in the wiki to avoid the types of developer anguish we see so regularly. BTW: I'm not at liberty to post the JUnit tests as they use my company's unit test suite framework. Regards, Michael Erskine. From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 06:18:04 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 18:48:04 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Hello Michael, I tried out your suggestion but the problem is that the read(rawbuf) blocks until the entire length of the rawbuf array has been read (blocking). I cannot decide on a reasonable size of the array because it varies from 2 bytes to as much as 50 byes (i'm communicating with a modem,each response is of a different length), which is why i wanted to use non blocking calls. But on a side note, read(byte[]) in turn calls the read() in a loop.In the native C function, the read is supposed to return a -1 upon timeout.But my driver does not support timeout.The default timeout value is zero and the linux select call upon zero time out causes an infinite wait.What am i missing...... Thanks and regards, Ravi Date: Wed, 3 Feb 2010 09:26:50 +0000 From: Michael Erskine To: "rxtx at qbang.org" Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: Content-Type: text/plain; charset="us-ascii" > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From m.kirkland at comcast.net Wed Feb 3 06:46:03 2010 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 3 Feb 2010 05:46:03 -0800 Subject: [Rxtx] One port blocking another port In-Reply-To: References: Message-ID: <68768633814F4D7D86761D34F0764FE0@bengal.net> It turns out this is caused by having the RTS/CTS flow control turned on and me not providing a true on the RTS pin. Somehow it seems the port timing out on a read allows the write to proceed. This is not an issue for my application but I wonder if the write should not proceed until the RTS pin is true even if a read times out. mk -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Monday, January 25, 2010 7:48 PM To: Mike Kirkland Cc: rxtx at qbang.org Subject: Re: [Rxtx] One port blocking another port On Mon, 25 Jan 2010, Mike Kirkland wrote: > > Hi All, > > ? > > I have a program that reads from one com port and writes to another com > port. It also does the same thing in reverse (reads from the second com port > and writes to the first one. It basically ties two com ports together. > > ? > > One port is very chatty and has a consent stream of data. The other port has > very little data. > > ? > > Both ports use a 5000 ms (5 second) time out. > > ? > > The issue I am having is that is appears that the first port?s write to the > second port is blocked while the second port is waiting for input. The first > port?s write proceeds only after the second port has timed out. > > ? > > I suppose I could have something twisted around in my code but I was > wondering if this is a know issue? > Hi Kirk, I've not seen a report like this. Perhaps some simple reproduction code will reveal a problem on your end or help us identify a problem in rxtx. I think there are several users doing multiport communication. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Wed Feb 3 07:03:58 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:03:58 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Message-ID: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> 2010/2/3 Ravishankar N > Hello Michael, > [..] > But on a side note, read(byte[]) in turn calls the read() in a loop.In the > native C function, the read is supposed to return a -1 upon timeout.But my > driver > does not support timeout.The default timeout value is zero and the linux > select call upon zero time out causes an infinite wait.What am i > missing...... > > When I have tested RXTX between platforms, I have observed "hangup" inside JNI driver when no data in Linux, is normal thing. Solution was setting the timeout for RXTX when no data from JNI driver. Something like that: commPort.enableReceiveTimeout(10); And it works perfect.... The only difference is that I am NOT using events - I am using continous read in separate thread and if data is available, is parsed and transferred to application using exception. Regards Mariusz > Thanks and regards, > Ravi > > Date: Wed, 3 Feb 2010 09:26:50 +0000 > From: Michael Erskine > To: "rxtx at qbang.org" > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > Message-ID: > > > Content-Type: text/plain; charset="us-ascii" > > > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of > > Ravishankar N > > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > > > My serial port driver(apparently) does not support receive timeout.I > > registered an event listener for DATA_AVAILABLE. However, the control > never > > seems to come out of the 'while' loop.Shouldn't the > > InputStream.read return a '-1' immediately if no data is available (this > seems > > to be the default operation)? > > Your event handler should handle the event and return immediately so that > its controlling thread can handle other events. I recommend a single read in > the following manner: rawbuf is a byte[] of "reasonable" size and the > read(byte[]) reads all available bytes up to the size of the buffer > returning the number of bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } > > This style of reading has worked for me with RXTX on Linux and Windows XP > for a good few years now in railway industry communications systems. Any > timeouts (largely unnecessary in my applications) can be handled elsewhere, > usually at a higher layer. > > Regards, > Michael Erskine. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Feb 3 07:22:55 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 3 Feb 2010 09:22:55 -0500 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: I'm guessing that this is driver specific. I recently had to support a select()/poll() infrastructure for a linux serial DD, its certainly non trivial to support async IO, so I suspect the problem in this case has to do with missing poll infrastructure in the device driver. This also has to coupled with special open flags for the device (which is within the rxtx code) The key routines within a 2.6 kernel linux device driver are shown below (if you have access to it for your particular device) are indicated below (here is a snippet from my device driver c code that supports polling/select). User space code to test this shown below also, note that the device needs to be opened with the O_NONBLOCK option to support the select/poll api // device driver code ..... /* * File operations supported by this driver. */ static struct file_operations iop_fops = { .owner = THIS_MODULE, .check_flags= iop_check_flags, .ioctl = iop_ioctl, .open = iop_open, .poll = iop_poll, // SUPPORT FOR SELECT/POLL infrastructure .read = iop_read, .release = iop_release, .write = iop_write, }; /** * Select/poll/epoll infrastructure. * * @param file * @param wait * * @return */ static unsigned int iop_poll(struct file *filp, poll_table *wait) { struct iop_device *devp = (struct iop_device *)filp->private_data; // the poll_table wait arg is an opaque pointer poll_wait(filp, &devp->readq, wait); // return from poll indicating whether we have read/write data unsigned int mask = 0; if (kfifo_len(devp->rx_fifo)) { mask |= (POLLIN | POLLRDNORM); } // @JC We don't do select on write yet // if (kfifo_len(devp->tx_fifo)) { // mask |= (POLLOUT | POLLWRNORM); // } // Only print out while debugging // if (mask != 0) { // printk (KERN_INFO "%s: [%04x]\n", __FUNCTION__, mask); // } return mask; } /** * device driver blocking and non blocking read function. This * function reads the requested number of bytes from the read * kfifo blocking as required. * * @param filp * @param buf * @param count * @param f_pos * * @return */ static ssize_t iop_read(struct file *filp, char __user *buf, size_t count, loff_t * ppos) { // access appropriate device struct struct iop_device *devp = (struct iop_device *) filp->private_data; ssize_t retval; // support non blocking mode (default) by checking if the kfifo is empty first if ((kfifo_len(devp->rx_fifo)==0) && (filp->f_flags & O_NONBLOCK)) { return -EAGAIN; } // wait for rx_fifo to receive data via receive interrupts retval = wait_event_interruptible(devp->readq, kfifo_len(devp->rx_fifo) != 0); // check for some error condition if (retval) { printk (KERN_ERR "%s: wait_event_interruptible returned[%d]\n", __FUNCTION__, retval); return retval; } // copy max requested bytes from rx_fifo to device buffer // this may still leave bytes in the kfifo for a subsequent read // if we are reading in a loop retval = kfifo_get(devp->rx_fifo, devp->rxbuf, count); // printk (KERN_INFO "%s: [%d] byte(s)\n", __FUNCTION__, retval); if (copy_to_user(buf, devp->rxbuf, retval)) { printk (KERN_ERR "%s: problem copying rx_fifo data to user buffer\n", __FUNCTION__); return -EFAULT; } return retval; } // a selection of my user space code reading via select()/poll()..... // user space open code iop_fd = ::open( deviceName.data(), O_RDWR | O_NONBLOCK); while ((bytes_to_expect - bytes_read) > 0) { // must reinitialize these between select calls fd_set readfds; FD_ZERO( &readfds ); FD_SET( iop_fd, &readfds ); // 1s sec read polling timeout struct timeval timeout; timeout.tv_sec = 1; timeout.tv_usec = 0; int rc = select( FD_SETSIZE, &readfds, NULL, NULL, &timeout ); // read from file when descriptor // indicates data available without blocking if ((rc > 0) && FD_ISSET(iop_fd, &readfds)) { // read into the appropriate offset within the rx_buf int temp = read(iop_fd, rx_buf + bytes_read, bytes_to_expect - bytes_read); if (!temp) { printf("EOF detected with %d bytes expected\n", bytes_to_expect - bytes_read); } else { bytes_read += temp; } } else if (rc < 0){ printf("%s: select on [%s], bytes_read[%d], errno=%d\n", __FUNCTION__, thread_args->device, bytes_read, errno); } else { printf("%s: select on [%s], bytes_read[%d], timeout\n", __FUNCTION__, thread_args->device, bytes_read); } } On Wed, Feb 3, 2010 at 9:03 AM, Mariusz Dec wrote: > > > 2010/2/3 Ravishankar N > >> Hello Michael, >> [..] >> >> But on a side note, read(byte[]) in turn calls the read() in a loop.In the >> native C function, the read is supposed to return a -1 upon timeout.But my >> driver >> does not support timeout.The default timeout value is zero and the linux >> select call upon zero time out causes an infinite wait.What am i >> missing...... >> >> > When I have tested RXTX between platforms, I have observed "hangup" inside > JNI driver when no data in Linux, is normal thing. > > Solution was setting the timeout for RXTX when no data from JNI driver. > > Something like that: > > commPort.enableReceiveTimeout(10); > > And it works perfect.... > > The only difference is that I am NOT using events - I am using continous > read in separate thread and if data is available, is parsed and transferred > to application using exception. > > Regards > Mariusz > > > >> Thanks and regards, >> Ravi >> >> Date: Wed, 3 Feb 2010 09:26:50 +0000 >> From: Michael Erskine >> To: "rxtx at qbang.org" >> Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? >> Message-ID: >> >> >> Content-Type: text/plain; charset="us-ascii" >> >> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >> Of >> > Ravishankar N >> > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? >> > >> > My serial port driver(apparently) does not support receive timeout.I >> > registered an event listener for DATA_AVAILABLE. However, the control >> never >> > seems to come out of the 'while' loop.Shouldn't the >> > InputStream.read return a '-1' immediately if no data is available (this >> seems >> > to be the default operation)? >> >> Your event handler should handle the event and return immediately so that >> its controlling thread can handle other events. I recommend a single read in >> the following manner: rawbuf is a byte[] of "reasonable" size and the >> read(byte[]) reads all available bytes up to the size of the buffer >> returning the number of bytes actually read... >> >> case SerialPortEvent.DATA_AVAILABLE: >> try { >> int i = is.read(rawbuf); >> if (i == -1) { >> << process EOF condition - should never happen >> >> return; >> } >> << process bytes (rawbuf, i); >> >> return; >> } catch (IOException e) { >> << promptly deal with exception >> >> return; >> } >> >> This style of reading has worked for me with RXTX on Linux and Windows XP >> for a good few years now in railway industry communications systems. Any >> timeouts (largely unnecessary in my applications) can be handled elsewhere, >> usually at a higher layer. >> >> Regards, >> Michael Erskine. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Feb 3 07:33:27 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:33:27 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: <73a89f361002030633j682610afia48dc7accd8e049b@mail.gmail.com> 2010/2/3 John Coffey > I'm guessing that this is driver specific. I recently had to support a > select()/poll() infrastructure for a linux serial DD, its certainly non > trivial to support async IO, so I suspect the problem in this case has to do > with missing poll infrastructure in the device driver. This also has to > coupled with special open flags for the device (which is within the rxtx > code) > > Yes, you are right, it may be driver specific, but in my case I haven't changed blocking JNI driver. I have added ONLY one call to RXTX method mentioned in my previous post and blocking (as seen as from Java app) gone out... Maybe this is not elegant, but works without problem in my app. I am using only FTDI chips and their drivers from couple of years and maybe this is the kind of the way to have no many problems with serial as well? Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From andyrxtx at g0poy.co.uk Wed Feb 3 11:09:04 2010 From: andyrxtx at g0poy.co.uk (andyrxtx at g0poy.co.uk) Date: Wed, 3 Feb 2010 18:09:04 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes Message-ID: <20100203180904.164f24dd@workstation.site> ?Hello RXTX group, I have just joined this group, and this is my first posting. I wanted to pass on some information regarding rxtx, so apologies if this has been brought up before. I have searched back through the archives but nothing specific came up. I am not a Java programmer, and I only came across rxtx a few days ago. I use a piece of test equipment called a miniVNA http://www.miniradiosolutions.com/ This is a serial USB controlled instrument, and it has control software available for MS windows, and a very old and now non-working Linux application. A few days ago Dietmar, DL2SBA released a Java application to control the miniVNA, obviously this application makes use of rxtx. The program worked fine on Windows, so I set about installing it onto Linux. I use SUSE11.1 After a few false starts, I got the system running fairly easily, sorting out the file locking by adding the uucp group to the users account as suggested (I used the 2.2pre binary files) I then passed the install instructions onto another miniVNA user, who also uses SUSE, but he ran into problems. To cut a long story short, he was also having file lock problems, but the uucp fix did not work. Digging into his system I found that there have been some changes in SUSE 11.2. tty ports are now assigned to the dialout group rather than uucp. A hint in the rxtx INSTALL file, suggested that var/lock needs to be checked, so: SUSE 11.1, var/lock is root:uucp SUSE 11.2 var/lock is root:root A search on Google brought up several comments regarding this, and also a bugzilla entry. https://bugzilla.novell.com/show_bug.cgi?id=552095 However from reading the various posts, some of which are in the bugzilla entry, it appears that many distros may be, or have changed to this configuration, and this will undoubtedly break several things, rxtx included. I solved my fellow SUSE users problem by compiling the rxtx libs with the no lock file option during configure, and that solved his problem. As this issue will probably take some time to get resolved across all the various Linux distros, it might be worth considering changing the default on the Linux build of rxtx not to use lockfiles, or provide the two versions of the lib in the binary archive. Thanks for your indulgence Andy From damorales at gmail.com Wed Feb 3 11:33:23 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 15:33:23 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203180904.164f24dd@workstation.site> References: <20100203180904.164f24dd@workstation.site> Message-ID: Hi I had the same problem in Mandriva 2010 and yes, adding the user to the uucp group did not work as it used to be in earlier versions of linux distros, causing RXTX to not work as non root user. The problem appears because the existense of UDEV, now you MUST add a RULE so the group (uucp or whatever) have access (Read, Write, Execute) to the Serial Port. To solve the problem, without needing to recompile RXTX, you must add a rule to grant permissions (0666) to the group for the device or port (tty*, ttyUSB*, etc). I do not remember now what is the line i added but when i come back home i will give it to you (i am at work now). Greetings ! 2010/2/3 > Hello RXTX group, > > I have just joined this group, and this is my first posting. > I wanted to pass on some information regarding rxtx, so apologies if > this has been brought up before. I have searched back through the > archives but nothing specific came up. > > I am not a Java programmer, and I only came across rxtx a few days ago. > > I use a piece of test equipment called a miniVNA > http://www.miniradiosolutions.com/ > > This is a serial USB controlled instrument, and it has control software > available for MS windows, and a very old and now non-working Linux > application. > > A few days ago Dietmar, DL2SBA released a Java application to control the > miniVNA, obviously this application makes use of rxtx. > > The program worked fine on Windows, so I set about installing it onto > Linux. I use SUSE11.1 After a few false starts, I got the system running > fairly easily, sorting out the file locking by adding the uucp group to > the users account as suggested (I used the 2.2pre binary files) I then > passed the install instructions onto another miniVNA user, who also uses > SUSE, but he ran into problems. To cut a long story short, he was > also having file lock problems, but the uucp fix did not work. Digging > into his system I found that there have been some changes in SUSE 11.2. > > tty ports are now assigned to the dialout group rather than uucp. > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > checked, so: > > SUSE 11.1, var/lock is root:uucp > SUSE 11.2 var/lock is root:root > > A search on Google brought up several comments regarding this, and also > a bugzilla entry. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > However from reading the various posts, some of which are in the bugzilla > entry, it appears that many distros may be, or have changed to this > configuration, and this will undoubtedly break several things, rxtx > included. > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > no lock file option during configure, and that solved his problem. > > As this issue will probably take some time to get resolved across all the > various Linux distros, it might be worth considering changing the default > on the Linux build of rxtx not to use lockfiles, or provide the two > versions of the lib in the binary archive. > > Thanks for your indulgence > > Andy > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Wed Feb 3 12:07:02 2010 From: andy at g0poy.com (Andy Eskelson) Date: Wed, 3 Feb 2010 19:07:02 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> Message-ID: <20100203190702.1b0e7015@workstation.site> Thanks Daniel, I am aware of the permissions problem, I have had a udev rules to solve this for other programs for some time. . I don't think that this is the same problem. as far as I can understand things, the lock files are written in var/lock. Previously var/lock and dev/tty-whatever were the same group. Now with var/lock owned by and with a group of root:root anything other than root cannot create a lock file. Even minicom is broken by this change. This change is going to have quite a few knock-on effects I think. Andy On Wed, 3 Feb 2010 15:33:23 -0300 Daniel Morales Salas wrote: > Hi > > I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > group did not work as it used to be in earlier versions of linux distros, > causing RXTX to not work as non root user. > > The problem appears because the existense of UDEV, now you MUST add a RULE > so the group (uucp or whatever) have access (Read, Write, Execute) to the > Serial Port. > > To solve the problem, without needing to recompile RXTX, you must add a rule > to grant permissions (0666) to the group for the device or port (tty*, > ttyUSB*, etc). I do not remember now what is the line i added but when i > come back home i will give it to you (i am at work now). > > Greetings ! > > 2010/2/3 > > > Hello RXTX group, > > > > I have just joined this group, and this is my first posting. > > I wanted to pass on some information regarding rxtx, so apologies if > > this has been brought up before. I have searched back through the > > archives but nothing specific came up. > > > > I am not a Java programmer, and I only came across rxtx a few days ago. > > > > I use a piece of test equipment called a miniVNA > > http://www.miniradiosolutions.com/ > > > > This is a serial USB controlled instrument, and it has control software > > available for MS windows, and a very old and now non-working Linux > > application. > > > > A few days ago Dietmar, DL2SBA released a Java application to control the > > miniVNA, obviously this application makes use of rxtx. > > > > The program worked fine on Windows, so I set about installing it onto > > Linux. I use SUSE11.1 After a few false starts, I got the system running > > fairly easily, sorting out the file locking by adding the uucp group to > > the users account as suggested (I used the 2.2pre binary files) I then > > passed the install instructions onto another miniVNA user, who also uses > > SUSE, but he ran into problems. To cut a long story short, he was > > also having file lock problems, but the uucp fix did not work. Digging > > into his system I found that there have been some changes in SUSE 11.2. > > > > tty ports are now assigned to the dialout group rather than uucp. > > > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > checked, so: > > > > SUSE 11.1, var/lock is root:uucp > > SUSE 11.2 var/lock is root:root > > > > A search on Google brought up several comments regarding this, and also > > a bugzilla entry. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > However from reading the various posts, some of which are in the bugzilla > > entry, it appears that many distros may be, or have changed to this > > configuration, and this will undoubtedly break several things, rxtx > > included. > > > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > > no lock file option during configure, and that solved his problem. > > > > As this issue will probably take some time to get resolved across all the > > various Linux distros, it might be worth considering changing the default > > on the Linux build of rxtx not to use lockfiles, or provide the two > > versions of the lib in the binary archive. > > > > Thanks for your indulgence > > > > Andy > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From thisdyingdream at gmail.com Wed Feb 3 12:32:35 2010 From: thisdyingdream at gmail.com (Steven Harms) Date: Wed, 3 Feb 2010 14:32:35 -0500 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203190702.1b0e7015@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: This is currently a bug in OpenSUSE that affects more than just rxtx, and is a result of unified udev rules. You can work around this by making udev change the group back to uucp until something more happens. https://bugzilla.novell.com/show_bug.cgi?id=552095 Thanks, Steve On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > Thanks Daniel, > > I am aware of the permissions problem, I have had a udev rules to solve > this for other programs for some time. > . > I don't think that this is the same problem. as far as I can understand > things, the lock files are written in var/lock. Previously var/lock and > dev/tty-whatever were the same group. Now with var/lock owned by and with > a group of root:root anything other than root cannot create a lock > file. Even minicom is broken by this change. > > This change is going to have quite a few knock-on effects I think. > > > Andy > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > Daniel Morales Salas wrote: > >> Hi >> >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp >> group did not work as it used to be in earlier versions of linux distros, >> causing RXTX to not work as non root user. >> >> The problem appears because the existense of UDEV, now you MUST add a RULE >> so the group (uucp or whatever) have access (Read, Write, Execute) to the >> Serial Port. >> >> To solve the problem, without needing to recompile RXTX, you must add a rule >> to grant permissions (0666) to the group for the device or port (tty*, >> ttyUSB*, etc). I do not remember now what is the line i added but when i >> come back home i will give it to you (i am at work now). >> >> Greetings ! >> >> 2010/2/3 >> >> > Hello RXTX group, >> > >> > I have just joined this group, and this is my first posting. >> > I wanted to pass on ?some information regarding rxtx, so apologies if >> > this has been brought up before. I have searched back through the >> > archives but nothing specific came up. >> > >> > I am not a Java programmer, and I only came across rxtx a few days ago. >> > >> > I use a piece of test equipment called a miniVNA >> > http://www.miniradiosolutions.com/ >> > >> > This is a serial USB controlled instrument, and it has control software >> > available for MS windows, and a very old and now non-working Linux >> > application. >> > >> > A few days ago Dietmar, DL2SBA released a Java application to control the >> > miniVNA, obviously this application makes use of rxtx. >> > >> > The program worked fine on Windows, so I set about installing it onto >> > Linux. I use SUSE11.1 After a few false starts, I got the system running >> > fairly easily, sorting out the file locking by adding the uucp group to >> > the users account as suggested (I used the 2.2pre binary files) I then >> > passed the install instructions onto another miniVNA user, who also uses >> > SUSE, but he ran into problems. To cut a long story short, he was >> > also having file lock problems, but the uucp fix did not work. Digging >> > into his system I found that there have been some changes in SUSE 11.2. >> > >> > tty ports are now assigned to the dialout group rather than uucp. >> > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be >> > checked, so: >> > >> > SUSE 11.1, var/lock is root:uucp >> > SUSE 11.2 var/lock is root:root >> > >> > A search on Google brought up several comments regarding this, and also >> > a ?bugzilla entry. >> > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 >> > >> > However from reading the various posts, some of which are in the bugzilla >> > entry, it appears that many distros may be, or have changed to this >> > configuration, and this will undoubtedly break several things, rxtx >> > included. >> > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the >> > no lock file option during configure, and that solved his problem. >> > >> > As this issue will probably take some time to get resolved across all the >> > various Linux distros, it might be worth considering changing the default >> > on the Linux build of rxtx not to use lockfiles, or provide the two >> > versions of the lib in the binary archive. >> > >> > Thanks for your indulgence >> > >> > Andy >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> >> >> >> -- >> Atte: >> Daniel Dario Morales Salas >> Ingeniero Civil en Computaci?n e Inform?tica >> Tel?fono: 02 684 3417 >> Celular: 09 643 1802 >> Santiago, Chile > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 WWW: http://www.sharms.org/blog From andy at g0poy.com Wed Feb 3 17:58:29 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 00:58:29 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: <20100204005829.7dc944e1@workstation.site> Thanks Steve, changing the serial ports back the uucp is not a big problem. I have a udev rule that can be easily modified already. However I cannot see any way of dealing with the var/lock problem apart from making it writable to all. Any thoughts? Andy On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms wrote: > This is currently a bug in OpenSUSE that affects more than just rxtx, > and is a result of unified udev rules. You can work around this by > making udev change the group back to uucp until something more > happens. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > Thanks, > > Steve > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > Thanks Daniel, > > > > I am aware of the permissions problem, I have had a udev rules to solve > > this for other programs for some time. > > . > > I don't think that this is the same problem. as far as I can understand > > things, the lock files are written in var/lock. Previously var/lock and > > dev/tty-whatever were the same group. Now with var/lock owned by and with > > a group of root:root anything other than root cannot create a lock > > file. Even minicom is broken by this change. > > > > This change is going to have quite a few knock-on effects I think. > > > > > > Andy > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > Daniel Morales Salas wrote: > > > >> Hi > >> > >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > >> group did not work as it used to be in earlier versions of linux distros, > >> causing RXTX to not work as non root user. > >> > >> The problem appears because the existense of UDEV, now you MUST add a RULE > >> so the group (uucp or whatever) have access (Read, Write, Execute) to the > >> Serial Port. > >> > >> To solve the problem, without needing to recompile RXTX, you must add a rule > >> to grant permissions (0666) to the group for the device or port (tty*, > >> ttyUSB*, etc). I do not remember now what is the line i added but when i > >> come back home i will give it to you (i am at work now). > >> > >> Greetings ! > >> > >> 2010/2/3 > >> > >> > Hello RXTX group, > >> > > >> > I have just joined this group, and this is my first posting. > >> > I wanted to pass on ?some information regarding rxtx, so apologies if > >> > this has been brought up before. I have searched back through the > >> > archives but nothing specific came up. > >> > > >> > I am not a Java programmer, and I only came across rxtx a few days ago. > >> > > >> > I use a piece of test equipment called a miniVNA > >> > http://www.miniradiosolutions.com/ > >> > > >> > This is a serial USB controlled instrument, and it has control software > >> > available for MS windows, and a very old and now non-working Linux > >> > application. > >> > > >> > A few days ago Dietmar, DL2SBA released a Java application to control the > >> > miniVNA, obviously this application makes use of rxtx. > >> > > >> > The program worked fine on Windows, so I set about installing it onto > >> > Linux. I use SUSE11.1 After a few false starts, I got the system running > >> > fairly easily, sorting out the file locking by adding the uucp group to > >> > the users account as suggested (I used the 2.2pre binary files) I then > >> > passed the install instructions onto another miniVNA user, who also uses > >> > SUSE, but he ran into problems. To cut a long story short, he was > >> > also having file lock problems, but the uucp fix did not work. Digging > >> > into his system I found that there have been some changes in SUSE 11.2. > >> > > >> > tty ports are now assigned to the dialout group rather than uucp. > >> > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > >> > checked, so: > >> > > >> > SUSE 11.1, var/lock is root:uucp > >> > SUSE 11.2 var/lock is root:root > >> > > >> > A search on Google brought up several comments regarding this, and also > >> > a ?bugzilla entry. > >> > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > >> > > >> > However from reading the various posts, some of which are in the bugzilla > >> > entry, it appears that many distros may be, or have changed to this > >> > configuration, and this will undoubtedly break several things, rxtx > >> > included. > >> > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the > >> > no lock file option during configure, and that solved his problem. > >> > > >> > As this issue will probably take some time to get resolved across all the > >> > various Linux distros, it might be worth considering changing the default > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > >> > versions of the lib in the binary archive. > >> > > >> > Thanks for your indulgence > >> > > >> > Andy > >> > > >> > _______________________________________________ > >> > Rxtx mailing list > >> > Rxtx at qbang.org > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > >> > >> > >> > >> -- > >> Atte: > >> Daniel Dario Morales Salas > >> Ingeniero Civil en Computaci?n e Inform?tica > >> Tel?fono: 02 684 3417 > >> Celular: 09 643 1802 > >> Santiago, Chile > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > WWW: http://www.sharms.org/blog From damorales at gmail.com Wed Feb 3 18:26:38 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 22:26:38 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100204005829.7dc944e1@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: Hello I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva 2010 this is what i get: drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ and i don't have ANY problem with lock files and RXTX in my java software. All i had to do was add this rule to udev: # serial KERNEL=="tty*", GROUP="uucp", MODE="0666" and that was all. Of course my user (metalklesk) is part of uucp group. I did not make /var/lock writable to all users. Greetings ! 2010/2/3 Andy Eskelson > Thanks Steve, > > changing the serial ports back the uucp is not a big problem. I have a > udev rule that can be easily modified already. However I cannot see any > way of dealing with the var/lock problem apart from making it writable to > all. Any thoughts? > > Andy > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > wrote: > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > and is a result of unified udev rules. You can work around this by > > making udev change the group back to uucp until something more > > happens. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > Thanks, > > > > Steve > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > Thanks Daniel, > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > this for other programs for some time. > > > . > > > I don't think that this is the same problem. as far as I can understand > > > things, the lock files are written in var/lock. Previously var/lock and > > > dev/tty-whatever were the same group. Now with var/lock owned by and > with > > > a group of root:root anything other than root cannot create a lock > > > file. Even minicom is broken by this change. > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > Daniel Morales Salas wrote: > > > > > >> Hi > > >> > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > the uucp > > >> group did not work as it used to be in earlier versions of linux > distros, > > >> causing RXTX to not work as non root user. > > >> > > >> The problem appears because the existense of UDEV, now you MUST add a > RULE > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > the > > >> Serial Port. > > >> > > >> To solve the problem, without needing to recompile RXTX, you must add > a rule > > >> to grant permissions (0666) to the group for the device or port (tty*, > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > i > > >> come back home i will give it to you (i am at work now). > > >> > > >> Greetings ! > > >> > > >> 2010/2/3 > > >> > > >> > Hello RXTX group, > > >> > > > >> > I have just joined this group, and this is my first posting. > > >> > I wanted to pass on some information regarding rxtx, so apologies > if > > >> > this has been brought up before. I have searched back through the > > >> > archives but nothing specific came up. > > >> > > > >> > I am not a Java programmer, and I only came across rxtx a few days > ago. > > >> > > > >> > I use a piece of test equipment called a miniVNA > > >> > http://www.miniradiosolutions.com/ > > >> > > > >> > This is a serial USB controlled instrument, and it has control > software > > >> > available for MS windows, and a very old and now non-working Linux > > >> > application. > > >> > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > control the > > >> > miniVNA, obviously this application makes use of rxtx. > > >> > > > >> > The program worked fine on Windows, so I set about installing it > onto > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > running > > >> > fairly easily, sorting out the file locking by adding the uucp group > to > > >> > the users account as suggested (I used the 2.2pre binary files) I > then > > >> > passed the install instructions onto another miniVNA user, who also > uses > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > >> > also having file lock problems, but the uucp fix did not work. > Digging > > >> > into his system I found that there have been some changes in SUSE > 11.2. > > >> > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > >> > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > >> > checked, so: > > >> > > > >> > SUSE 11.1, var/lock is root:uucp > > >> > SUSE 11.2 var/lock is root:root > > >> > > > >> > A search on Google brought up several comments regarding this, and > also > > >> > a bugzilla entry. > > >> > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > >> > > > >> > However from reading the various posts, some of which are in the > bugzilla > > >> > entry, it appears that many distros may be, or have changed to this > > >> > configuration, and this will undoubtedly break several things, rxtx > > >> > included. > > >> > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > with the > > >> > no lock file option during configure, and that solved his problem. > > >> > > > >> > As this issue will probably take some time to get resolved across > all the > > >> > various Linux distros, it might be worth considering changing the > default > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > >> > versions of the lib in the binary archive. > > >> > > > >> > Thanks for your indulgence > > >> > > > >> > Andy > > >> > > > >> > _______________________________________________ > > >> > Rxtx mailing list > > >> > Rxtx at qbang.org > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > >> > > > >> > > >> > > >> > > >> -- > > >> Atte: > > >> Daniel Dario Morales Salas > > >> Ingeniero Civil en Computaci?n e Inform?tica > > >> Tel?fono: 02 684 3417 > > >> Celular: 09 643 1802 > > >> Santiago, Chile > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at qbang.org > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > -- > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > WWW: http://www.sharms.org/blog > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Thu Feb 4 05:31:46 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 12:31:46 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: <20100204123146.6cffeb67@workstation.site> Thank's for the confirmation. Something odd is going on somewhere in SUSE 11.2. I'll have to build up a local SUSE11.2 system to see if I can nail down exactly what is going on. Something is blocking the lockfiles in var/lock. The net is nice, but it's a bit difficult trying to work out what is going on what the machine in question is in Germany and I'm in the UK :-) Andy On Wed, 3 Feb 2010 22:26:38 -0300 Daniel Morales Salas wrote: > Hello > > I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva > 2010 this is what i get: > > drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ > > and i don't have ANY problem with lock files and RXTX in my java software. > All i had to do was add this rule to udev: > > # serial > KERNEL=="tty*", GROUP="uucp", MODE="0666" > > and that was all. Of course my user (metalklesk) is part of uucp group. > I did not make /var/lock writable to all users. > > Greetings ! > > 2010/2/3 Andy Eskelson > > > Thanks Steve, > > > > changing the serial ports back the uucp is not a big problem. I have a > > udev rule that can be easily modified already. However I cannot see any > > way of dealing with the var/lock problem apart from making it writable to > > all. Any thoughts? > > > > Andy > > > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > > wrote: > > > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > > and is a result of unified udev rules. You can work around this by > > > making udev change the group back to uucp until something more > > > happens. > > > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > > > Thanks, > > > > > > Steve > > > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > > Thanks Daniel, > > > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > > this for other programs for some time. > > > > . > > > > I don't think that this is the same problem. as far as I can understand > > > > things, the lock files are written in var/lock. Previously var/lock and > > > > dev/tty-whatever were the same group. Now with var/lock owned by and > > with > > > > a group of root:root anything other than root cannot create a lock > > > > file. Even minicom is broken by this change. > > > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > > Daniel Morales Salas wrote: > > > > > > > >> Hi > > > >> > > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > > the uucp > > > >> group did not work as it used to be in earlier versions of linux > > distros, > > > >> causing RXTX to not work as non root user. > > > >> > > > >> The problem appears because the existense of UDEV, now you MUST add a > > RULE > > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > > the > > > >> Serial Port. > > > >> > > > >> To solve the problem, without needing to recompile RXTX, you must add > > a rule > > > >> to grant permissions (0666) to the group for the device or port (tty*, > > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > > i > > > >> come back home i will give it to you (i am at work now). > > > >> > > > >> Greetings ! > > > >> > > > >> 2010/2/3 > > > >> > > > >> > Hello RXTX group, > > > >> > > > > >> > I have just joined this group, and this is my first posting. > > > >> > I wanted to pass on some information regarding rxtx, so apologies > > if > > > >> > this has been brought up before. I have searched back through the > > > >> > archives but nothing specific came up. > > > >> > > > > >> > I am not a Java programmer, and I only came across rxtx a few days > > ago. > > > >> > > > > >> > I use a piece of test equipment called a miniVNA > > > >> > http://www.miniradiosolutions.com/ > > > >> > > > > >> > This is a serial USB controlled instrument, and it has control > > software > > > >> > available for MS windows, and a very old and now non-working Linux > > > >> > application. > > > >> > > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > > control the > > > >> > miniVNA, obviously this application makes use of rxtx. > > > >> > > > > >> > The program worked fine on Windows, so I set about installing it > > onto > > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > > running > > > >> > fairly easily, sorting out the file locking by adding the uucp group > > to > > > >> > the users account as suggested (I used the 2.2pre binary files) I > > then > > > >> > passed the install instructions onto another miniVNA user, who also > > uses > > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > > >> > also having file lock problems, but the uucp fix did not work. > > Digging > > > >> > into his system I found that there have been some changes in SUSE > > 11.2. > > > >> > > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > > >> > > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > > >> > checked, so: > > > >> > > > > >> > SUSE 11.1, var/lock is root:uucp > > > >> > SUSE 11.2 var/lock is root:root > > > >> > > > > >> > A search on Google brought up several comments regarding this, and > > also > > > >> > a bugzilla entry. > > > >> > > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > >> > > > > >> > However from reading the various posts, some of which are in the > > bugzilla > > > >> > entry, it appears that many distros may be, or have changed to this > > > >> > configuration, and this will undoubtedly break several things, rxtx > > > >> > included. > > > >> > > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > > with the > > > >> > no lock file option during configure, and that solved his problem. > > > >> > > > > >> > As this issue will probably take some time to get resolved across > > all the > > > >> > various Linux distros, it might be worth considering changing the > > default > > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > > >> > versions of the lib in the binary archive. > > > >> > > > > >> > Thanks for your indulgence > > > >> > > > > >> > Andy > > > >> > > > > >> > _______________________________________________ > > > >> > Rxtx mailing list > > > >> > Rxtx at qbang.org > > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > > >> > > > > >> > > > >> > > > >> > > > >> -- > > > >> Atte: > > > >> Daniel Dario Morales Salas > > > >> Ingeniero Civil en Computaci?n e Inform?tica > > > >> Tel?fono: 02 684 3417 > > > >> Celular: 09 643 1802 > > > >> Santiago, Chile > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at qbang.org > > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > > > -- > > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > > > WWW: http://www.sharms.org/blog > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From Bob_Jacobsen at lbl.gov Thu Feb 4 09:26:49 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Thu, 4 Feb 2010 08:26:49 -0800 Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 Message-ID: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're using RXTX-2.2pre2, although it emits the known message about "Version mismatch". WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 After the usual messing around, we've got it working on 11 Windows versions, multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ have things working rarely say so, so I don't know whether anybody has gotten it to work on 10.4 or not. The problem encountered is this: dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib dyld: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib followed by the JVM crashing hard. I've got those dump files if that would help. Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If so, is there a patch I can get and build? Thanks Bob -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From tjarvi at qbang.org Thu Feb 4 14:22:21 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 4 Feb 2010 14:22:21 -0700 (MST) Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 In-Reply-To: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> References: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> Message-ID: On Thu, 4 Feb 2010, Bob Jacobsen wrote: > We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're > using RXTX-2.2pre2, although it emits the known message about "Version > mismatch". > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > > After the usual messing around, we've got it working on 11 Windows versions, > multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with > a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ > have things working rarely say so, so I don't know whether anybody has gotten > it to work on 10.4 or not. > > The problem encountered is this: > > dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > dyld: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > followed by the JVM crashing hard. I've got those dump files if that would > help. > > Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If > so, is there a patch I can get and build? > Hi Bob, I talked to a coworker about the problem you ran into. It appears that it is possible to target 'older' Mac systems through makefile configuration changes. "Configuring a Makefile-Based Project If you have a makefile-based project, you can also take advantage of SDK-based development, by adding the appropriate options to your compile and link commands. Using SDKs in makefile-based projects requires GCC 4.0 or later. To choose an SDK, you use the -isysroot option with the compiler and the -syslibroot option with the linker. Both options require that you specify the full path to the desired SDK directory. To set the Deployment OS version in a makefile, use a makefile variable of the form: ENVP= MACOSX_DEPLOYMENT_TARGET=10.4. To use this variable in your makefile, include it in front of your compile and link commands." http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html Or build on the oldest system you want to support. -- Trent Jarvi tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Thu Feb 4 14:56:19 2010 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Thu, 4 Feb 2010 14:56:19 -0700 Subject: [Rxtx] RXTX on 64 Bit Redhat In-Reply-To: References: <4ec9eab61001281448g3dd84910r867619948a4e0d7a@mail.gmail.com> Message-ID: Trent -- Finally fixed all my build related issues. I ran into another issue. On one of my machines my JDK is returning multiple folders for the "java.ext.dirs" (java.ext.dirs -> /opt/jdk1.6.0_17/jre/lib/ext:/usr/java/packages/lib/ext) system property. As a result my JVM wasn't able to detect the gnu.io.rxtx.properties. I am attaching a patch for RXTXCommDriver.java file to check for multiple locations. Also i have to assign permission 660 to all my dev ports to be located by RXTX. Pawan ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 5:12 PM To: Trent Jarvi Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Here is the error i get when i build the src from release-2-1-7 -bash-3.2$ make ( \ \ cd i686-pc-linux-gnu; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/ jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I/opt/jav a1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec - c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialImp.lo;\ if [ "Serial" = "Serial" ]; then \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I /opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_tim espec -c /home/jb_stg/rxtx/rxtx-devel/./src/fuserImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ else \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo; \ fi; \ ) gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/inclu de -I/opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need _timespec -c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -fPIC -DPIC -o /hom e/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/.libs/SerialImp.o /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:25:29: error: gnu_io_RXTXPort.h: No such file or directory In file included from /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:113: /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:91: error: expected specifier-qua lifier-list before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'jobject' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:408: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:409: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:410: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:411: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:415: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:416: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:417: error: expected '=', ',', '; ', 'asm' or '__attribute__' before 'is_interrupted' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:418: error: expected declaration specifiers or '...' before 'jint' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:424: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:441: error: expected ')' before ' *' token ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 4:57 PM To: Santosh Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Santosh -- Thank you. That fixed the issue. All -- What CVS branch or release should i use to get the latest RXTX src code. Pawan ________________________________ From: Santosh [mailto:santosh.ry at gmail.com] Sent: Thursday, January 28, 2010 3:49 PM To: Kharbanda, Pawan Cc: Trent Jarvi; rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat error "./configure: /bin/sh^M: bad interpreter: No such file or directory". I think you need to run dos2unix on script files before compiling. Thanks, Santosh On Thu, Jan 28, 2010 at 5:33 PM, Kharbanda, Pawan > wrote: Trent -- We are upgrading our exisiting OS and JDK on a project that rely heavily on RXTX api's. We are now using JDK1.6 32 bit (build 1.6.0_17-b04) and RedHat 5 on a 64 bit machine. Linux tocrhstg02.dot.state.co.us 2.6.18-164.6.1.el5 #1 SMP Tue Oct 27 11:30:06 EDT 2009 i686 i686 i386 GNU/Linux Red Hat Enterprise Linux Server release 5.4 (Tikanga) I tried to run version 2.1.7 r2 on it but not able to see any of my Digi ports I was able to access only /dev/ttyS0 (physical ports). Not sure if the problem is with the Digi driver or RXTX. I tried to open a Digi port with minicom and it worked fine. I also tried to get latest from CVS (rxtx-devel) and when I do "configure" I see this error "./configure: /bin/sh^M: bad interpreter: No such file or directory". Can someone please help me with this? Thanks for the help. Pawan _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch.txt URL: From juan.vicente.l.g at gmail.com Sat Feb 13 04:44:17 2010 From: juan.vicente.l.g at gmail.com (Juan Vicente Lopez Gutierrez) Date: Sat, 13 Feb 2010 12:44:17 +0100 Subject: [Rxtx] RXTX in macmini OSX 10.5 Message-ID: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> Hello. My name is Juanvi and I'm from Spain. I tried to launch a software created by me in the library CXR java to send information through the serial port and I can not make it work. In windows if I've done but not mac. I have a mac mini with OSX 10.5 and have read in the list of web mail that you CXR if you have managed to make it work on that operating system. I need you help me please. Do I make the mistake that shows me java: run: Stable Library =============================== Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 gnu.io.PortInUseException: Unknow Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:26) at TwoWatSerialComm.main(TwoWaySerialComm.java:106) Experimental: JNI_OnLoad called. GENERACION CORRECTA (total time: 0 seconds) I do not have permission to access the serial port, do not know. Os agradeceria much to sit down. A greeting and thanks. Pardon my English. Juanvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From juan.vicente.l.g at gmail.com Sat Feb 13 14:39:41 2010 From: juan.vicente.l.g at gmail.com (Juan Vicente Lopez Gutierrez) Date: Sat, 13 Feb 2010 22:39:41 +0100 Subject: [Rxtx] Fwd: RXTX in macmini OSX 10.5 In-Reply-To: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> References: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> Message-ID: <29405e5c1002131339m2059d169sdc8549ed9706a1af@mail.gmail.com> ---------- Forwarded message ---------- From: Juan Vicente Lopez Gutierrez Date: 2010/2/13 Subject: RXTX in macmini OSX 10.5 To: rxtx at qbang.org Hello. My name is Juanvi and I'm from Spain. I tried to launch a software created by me in the library CXR java to send information through the serial port and I can not make it work. In windows if I've done but not mac. I have a mac mini with OSX 10.5 and have read in the list of web mail that you CXR if you have managed to make it work on that operating system. I need you help me please. Do I make the mistake that shows me java: run: Stable Library =============================== Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 gnu.io.PortInUseException: Unknow Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:26) at TwoWatSerialComm.main(TwoWaySerialComm.java:106) Experimental: JNI_OnLoad called. GENERACION CORRECTA (total time: 0 seconds) I do not have permission to access the serial port, do not know. Os agradeceria much to sit down. A greeting and thanks. Pardon my English. Juanvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Mon Feb 22 04:35:48 2010 From: george.dma at gmail.com (George H) Date: Mon, 22 Feb 2010 13:35:48 +0200 Subject: [Rxtx] Lingering rxtx process Message-ID: Hi, I am using RXTX v2.1-7. I use it to communicate with 2 serial receipt printers and 1 serial line display device. My program runs well using the RXTX library on Windows and Linux. But... when I installed Linux on another hardware the program does not exit properly. By this I mean that the java program seems to have exited (passed the System.exit(0)) code but the console still does not return to the bash shell. I have to CTRL+C each time to kill the program. And on each restart RXTX has to remove stale LCK files. Just note I am only getting this on one machine, if it makes any difference it is an i686 system with all VIA chipsets and VIA-C7M NannoBGA2 processor. Any ideas? Thanks -- George H george.dma at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Mon Feb 22 04:43:43 2010 From: george.dma at gmail.com (George H) Date: Mon, 22 Feb 2010 13:43:43 +0200 Subject: [Rxtx] Lingering rxtx process Message-ID: Hi, I am using RXTX v2.1-7. I use it to communicate with 2 serial receipt printers and 1 serial line display device. My program runs well using the RXTX library on Windows and Linux. But... when I installed Linux on another hardware the program does not exit properly. By this I mean that the java program seems to have exited (passed the System.exit(0)) code but the console still does not return to the bash shell. I have to CTRL+C each time to kill the program. And on each restart RXTX has to remove stale LCK files. Just note I am only getting this on one machine, if it makes any difference it is an i686 system with all VIA chipsets and VIA-C7M NannoBGA2 processor. Any ideas? Thanks -- George H george.dma at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Tue Feb 23 01:29:42 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Tue, 23 Feb 2010 09:29:42 +0100 Subject: [Rxtx] Lingering rxtx process In-Reply-To: References: Message-ID: <73a89f361002230029w4a9ec14bt56d654e43c1c9623@mail.gmail.com> 2010/2/22 George H > Hi, > > I am using RXTX v2.1-7. > I use it to communicate with 2 serial receipt printers and 1 serial line > display device. My program runs well using the RXTX library on Windows and > Linux. > But... when I installed Linux on another hardware the program does not exit > properly. By this I mean that the java program seems to have exited (passed > the System.exit(0)) code but the console still does not return to the bash > shell. > > Thread in Noember 2009' - http://mailman.qbang.org/pipermail/rxtx/2009-November/5778408.html I have disocvered one technique which solved this problem in Linux Ubuntu and Mac for RXTX pre2.2, but should helps in 2.1.7 as well. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Thu Feb 25 02:41:46 2010 From: george.dma at gmail.com (George H) Date: Thu, 25 Feb 2010 11:41:46 +0200 Subject: [Rxtx] Lingering rxtx process In-Reply-To: <73a89f361002230029w4a9ec14bt56d654e43c1c9623@mail.gmail.com> References: <73a89f361002230029w4a9ec14bt56d654e43c1c9623@mail.gmail.com> Message-ID: With Mariusz Dec help and with the help of the threads that were mentioned http://mailman.qbang.org/pipermail/rxtx/2009-November/5790326.html http://embeddedfreak.wordpress.com/2008/10/08/rxtx-serial-port-helper/ I managed to solved my problem. I didn't really like it so much. I am not using the InputStream.read(byte[], int, int) method as for me I can break out of reading the stream if I get a '\n' or a 0x00. Either way the below code sample works for me. int data = 0; int len = 0; while(true) { data = commReader.getInputStream().read(); if(data == -1 || data == 0x00 || data == '\n' || commReader.getInputStream().available() < 1) { break; } if(len == buffer.length) { processData(buffer); clearBuffer(); } buffer[len++] = (byte)data; } Before I would loop the while until data != -1. But that blocks on .close() and my program never gets to exit. Adding .available() < 1 as a break condition fixes it when I call .close() I am going to see if this is a linux kernel configuration issue or not cos it isn't so obvious and I hardly ever use .available() when reading streams. Love the project though :) -- George H george.dma at gmail.com On Tue, Feb 23, 2010 at 10:29 AM, Mariusz Dec wrote: > > > 2010/2/22 George H > > Hi, >> >> I am using RXTX v2.1-7. >> I use it to communicate with 2 serial receipt printers and 1 serial line >> display device. My program runs well using the RXTX library on Windows and >> Linux. >> But... when I installed Linux on another hardware the program does not >> exit properly. By this I mean that the java program seems to have exited >> (passed the System.exit(0)) code but the console still does not return to >> the bash shell. >> >> Thread in Noember 2009' - > > http://mailman.qbang.org/pipermail/rxtx/2009-November/5778408.html > > I have disocvered one technique which solved this problem in Linux Ubuntu > and Mac for RXTX pre2.2, but should helps in 2.1.7 as well. > > Regards > Mariusz > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 01:02:21 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 13:32:21 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> My serial port driver(apparently) does not support receive timeout.I registered an event listener for DATA_AVAILABLE. However, the control never seems to come out of the 'while' loop.Shouldn't the InputStream.read return a '-1' immediately if no data is available (this seems to be the default operation)? This was tried on a x86 Linux desktop using rxtx-2.1-7 I've added the snippet for clarity: /******************************************************************************************************************************************************************************/ mySerialPort.enableReceiveThreshold(2000);//Trying to set a time limit for read calls System.out.println(mySerialPort.isReceiveTimeoutEnabled()); // I get FALSE, so its not supported on hardware. mySerialPort.addEventListener(this); mySerialPort.notifyOnDataAvailable(true);//register a event with //my SerialEvent listener implementation: public void serialEvent(SerialPortEvent arg0) { int newData=0; switch(arg0.getEventType()){ case SerialPortEvent.DATA_AVAILABLE: while (newData != -1) { try { newData = is.read();//This should eventually return a -1 if no data is available within a timeout.PROBLEM!! System.out.println("Got a byte from port:"+newData); if (newData == -1) { break; } } catch (IOException ex) { System.err.println(ex); return; } } break; } return; } /******************************************************************************************************************************************************************************/ Thanks and regards, Ravi From michael.erskine at ketech.com Wed Feb 3 02:26:50 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 09:26:50 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From michael.erskine at ketech.com Wed Feb 3 05:03:30 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 12:03:30 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > Michael Erskine > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > > Your event handler should handle the event and return immediately so that its > controlling thread can handle other events. I recommend a single read in the > following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) > reads all available bytes up to the size of the buffer returning the number of > bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } After posting this I considered the glaring possibility of the rawbuf read buffer being too small to receive all the available bytes and perhaps skipping data: after all, I'm guessing that is why we see so many posts asking for help with blocking implementations of read event handlers looping on "while(bytes are available)". I've spent this morning writing an extensive multi-threaded unit test suite that includes tests with a tiny buffer compared to the amount of data available and found that no data was being skipped. I now want to know why! The SerialPortEvent.DATA_AVAILABLE event must be being fired again if there is more data available on the input stream. If that is the case then it should be heavily documented with good examples in the wiki to avoid the types of developer anguish we see so regularly. BTW: I'm not at liberty to post the JUnit tests as they use my company's unit test suite framework. Regards, Michael Erskine. From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 06:18:04 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 18:48:04 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Hello Michael, I tried out your suggestion but the problem is that the read(rawbuf) blocks until the entire length of the rawbuf array has been read (blocking). I cannot decide on a reasonable size of the array because it varies from 2 bytes to as much as 50 byes (i'm communicating with a modem,each response is of a different length), which is why i wanted to use non blocking calls. But on a side note, read(byte[]) in turn calls the read() in a loop.In the native C function, the read is supposed to return a -1 upon timeout.But my driver does not support timeout.The default timeout value is zero and the linux select call upon zero time out causes an infinite wait.What am i missing...... Thanks and regards, Ravi Date: Wed, 3 Feb 2010 09:26:50 +0000 From: Michael Erskine To: "rxtx at qbang.org" Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: Content-Type: text/plain; charset="us-ascii" > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From m.kirkland at comcast.net Wed Feb 3 06:46:03 2010 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 3 Feb 2010 05:46:03 -0800 Subject: [Rxtx] One port blocking another port In-Reply-To: References: Message-ID: <68768633814F4D7D86761D34F0764FE0@bengal.net> It turns out this is caused by having the RTS/CTS flow control turned on and me not providing a true on the RTS pin. Somehow it seems the port timing out on a read allows the write to proceed. This is not an issue for my application but I wonder if the write should not proceed until the RTS pin is true even if a read times out. mk -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Monday, January 25, 2010 7:48 PM To: Mike Kirkland Cc: rxtx at qbang.org Subject: Re: [Rxtx] One port blocking another port On Mon, 25 Jan 2010, Mike Kirkland wrote: > > Hi All, > > ? > > I have a program that reads from one com port and writes to another com > port. It also does the same thing in reverse (reads from the second com port > and writes to the first one. It basically ties two com ports together. > > ? > > One port is very chatty and has a consent stream of data. The other port has > very little data. > > ? > > Both ports use a 5000 ms (5 second) time out. > > ? > > The issue I am having is that is appears that the first port?s write to the > second port is blocked while the second port is waiting for input. The first > port?s write proceeds only after the second port has timed out. > > ? > > I suppose I could have something twisted around in my code but I was > wondering if this is a know issue? > Hi Kirk, I've not seen a report like this. Perhaps some simple reproduction code will reveal a problem on your end or help us identify a problem in rxtx. I think there are several users doing multiport communication. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Wed Feb 3 07:03:58 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:03:58 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Message-ID: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> 2010/2/3 Ravishankar N > Hello Michael, > [..] > But on a side note, read(byte[]) in turn calls the read() in a loop.In the > native C function, the read is supposed to return a -1 upon timeout.But my > driver > does not support timeout.The default timeout value is zero and the linux > select call upon zero time out causes an infinite wait.What am i > missing...... > > When I have tested RXTX between platforms, I have observed "hangup" inside JNI driver when no data in Linux, is normal thing. Solution was setting the timeout for RXTX when no data from JNI driver. Something like that: commPort.enableReceiveTimeout(10); And it works perfect.... The only difference is that I am NOT using events - I am using continous read in separate thread and if data is available, is parsed and transferred to application using exception. Regards Mariusz > Thanks and regards, > Ravi > > Date: Wed, 3 Feb 2010 09:26:50 +0000 > From: Michael Erskine > To: "rxtx at qbang.org" > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > Message-ID: > > > Content-Type: text/plain; charset="us-ascii" > > > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of > > Ravishankar N > > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > > > My serial port driver(apparently) does not support receive timeout.I > > registered an event listener for DATA_AVAILABLE. However, the control > never > > seems to come out of the 'while' loop.Shouldn't the > > InputStream.read return a '-1' immediately if no data is available (this > seems > > to be the default operation)? > > Your event handler should handle the event and return immediately so that > its controlling thread can handle other events. I recommend a single read in > the following manner: rawbuf is a byte[] of "reasonable" size and the > read(byte[]) reads all available bytes up to the size of the buffer > returning the number of bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } > > This style of reading has worked for me with RXTX on Linux and Windows XP > for a good few years now in railway industry communications systems. Any > timeouts (largely unnecessary in my applications) can be handled elsewhere, > usually at a higher layer. > > Regards, > Michael Erskine. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Feb 3 07:22:55 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 3 Feb 2010 09:22:55 -0500 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: I'm guessing that this is driver specific. I recently had to support a select()/poll() infrastructure for a linux serial DD, its certainly non trivial to support async IO, so I suspect the problem in this case has to do with missing poll infrastructure in the device driver. This also has to coupled with special open flags for the device (which is within the rxtx code) The key routines within a 2.6 kernel linux device driver are shown below (if you have access to it for your particular device) are indicated below (here is a snippet from my device driver c code that supports polling/select). User space code to test this shown below also, note that the device needs to be opened with the O_NONBLOCK option to support the select/poll api // device driver code ..... /* * File operations supported by this driver. */ static struct file_operations iop_fops = { .owner = THIS_MODULE, .check_flags= iop_check_flags, .ioctl = iop_ioctl, .open = iop_open, .poll = iop_poll, // SUPPORT FOR SELECT/POLL infrastructure .read = iop_read, .release = iop_release, .write = iop_write, }; /** * Select/poll/epoll infrastructure. * * @param file * @param wait * * @return */ static unsigned int iop_poll(struct file *filp, poll_table *wait) { struct iop_device *devp = (struct iop_device *)filp->private_data; // the poll_table wait arg is an opaque pointer poll_wait(filp, &devp->readq, wait); // return from poll indicating whether we have read/write data unsigned int mask = 0; if (kfifo_len(devp->rx_fifo)) { mask |= (POLLIN | POLLRDNORM); } // @JC We don't do select on write yet // if (kfifo_len(devp->tx_fifo)) { // mask |= (POLLOUT | POLLWRNORM); // } // Only print out while debugging // if (mask != 0) { // printk (KERN_INFO "%s: [%04x]\n", __FUNCTION__, mask); // } return mask; } /** * device driver blocking and non blocking read function. This * function reads the requested number of bytes from the read * kfifo blocking as required. * * @param filp * @param buf * @param count * @param f_pos * * @return */ static ssize_t iop_read(struct file *filp, char __user *buf, size_t count, loff_t * ppos) { // access appropriate device struct struct iop_device *devp = (struct iop_device *) filp->private_data; ssize_t retval; // support non blocking mode (default) by checking if the kfifo is empty first if ((kfifo_len(devp->rx_fifo)==0) && (filp->f_flags & O_NONBLOCK)) { return -EAGAIN; } // wait for rx_fifo to receive data via receive interrupts retval = wait_event_interruptible(devp->readq, kfifo_len(devp->rx_fifo) != 0); // check for some error condition if (retval) { printk (KERN_ERR "%s: wait_event_interruptible returned[%d]\n", __FUNCTION__, retval); return retval; } // copy max requested bytes from rx_fifo to device buffer // this may still leave bytes in the kfifo for a subsequent read // if we are reading in a loop retval = kfifo_get(devp->rx_fifo, devp->rxbuf, count); // printk (KERN_INFO "%s: [%d] byte(s)\n", __FUNCTION__, retval); if (copy_to_user(buf, devp->rxbuf, retval)) { printk (KERN_ERR "%s: problem copying rx_fifo data to user buffer\n", __FUNCTION__); return -EFAULT; } return retval; } // a selection of my user space code reading via select()/poll()..... // user space open code iop_fd = ::open( deviceName.data(), O_RDWR | O_NONBLOCK); while ((bytes_to_expect - bytes_read) > 0) { // must reinitialize these between select calls fd_set readfds; FD_ZERO( &readfds ); FD_SET( iop_fd, &readfds ); // 1s sec read polling timeout struct timeval timeout; timeout.tv_sec = 1; timeout.tv_usec = 0; int rc = select( FD_SETSIZE, &readfds, NULL, NULL, &timeout ); // read from file when descriptor // indicates data available without blocking if ((rc > 0) && FD_ISSET(iop_fd, &readfds)) { // read into the appropriate offset within the rx_buf int temp = read(iop_fd, rx_buf + bytes_read, bytes_to_expect - bytes_read); if (!temp) { printf("EOF detected with %d bytes expected\n", bytes_to_expect - bytes_read); } else { bytes_read += temp; } } else if (rc < 0){ printf("%s: select on [%s], bytes_read[%d], errno=%d\n", __FUNCTION__, thread_args->device, bytes_read, errno); } else { printf("%s: select on [%s], bytes_read[%d], timeout\n", __FUNCTION__, thread_args->device, bytes_read); } } On Wed, Feb 3, 2010 at 9:03 AM, Mariusz Dec wrote: > > > 2010/2/3 Ravishankar N > >> Hello Michael, >> [..] >> >> But on a side note, read(byte[]) in turn calls the read() in a loop.In the >> native C function, the read is supposed to return a -1 upon timeout.But my >> driver >> does not support timeout.The default timeout value is zero and the linux >> select call upon zero time out causes an infinite wait.What am i >> missing...... >> >> > When I have tested RXTX between platforms, I have observed "hangup" inside > JNI driver when no data in Linux, is normal thing. > > Solution was setting the timeout for RXTX when no data from JNI driver. > > Something like that: > > commPort.enableReceiveTimeout(10); > > And it works perfect.... > > The only difference is that I am NOT using events - I am using continous > read in separate thread and if data is available, is parsed and transferred > to application using exception. > > Regards > Mariusz > > > >> Thanks and regards, >> Ravi >> >> Date: Wed, 3 Feb 2010 09:26:50 +0000 >> From: Michael Erskine >> To: "rxtx at qbang.org" >> Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? >> Message-ID: >> >> >> Content-Type: text/plain; charset="us-ascii" >> >> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >> Of >> > Ravishankar N >> > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? >> > >> > My serial port driver(apparently) does not support receive timeout.I >> > registered an event listener for DATA_AVAILABLE. However, the control >> never >> > seems to come out of the 'while' loop.Shouldn't the >> > InputStream.read return a '-1' immediately if no data is available (this >> seems >> > to be the default operation)? >> >> Your event handler should handle the event and return immediately so that >> its controlling thread can handle other events. I recommend a single read in >> the following manner: rawbuf is a byte[] of "reasonable" size and the >> read(byte[]) reads all available bytes up to the size of the buffer >> returning the number of bytes actually read... >> >> case SerialPortEvent.DATA_AVAILABLE: >> try { >> int i = is.read(rawbuf); >> if (i == -1) { >> << process EOF condition - should never happen >> >> return; >> } >> << process bytes (rawbuf, i); >> >> return; >> } catch (IOException e) { >> << promptly deal with exception >> >> return; >> } >> >> This style of reading has worked for me with RXTX on Linux and Windows XP >> for a good few years now in railway industry communications systems. Any >> timeouts (largely unnecessary in my applications) can be handled elsewhere, >> usually at a higher layer. >> >> Regards, >> Michael Erskine. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Feb 3 07:33:27 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:33:27 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: <73a89f361002030633j682610afia48dc7accd8e049b@mail.gmail.com> 2010/2/3 John Coffey > I'm guessing that this is driver specific. I recently had to support a > select()/poll() infrastructure for a linux serial DD, its certainly non > trivial to support async IO, so I suspect the problem in this case has to do > with missing poll infrastructure in the device driver. This also has to > coupled with special open flags for the device (which is within the rxtx > code) > > Yes, you are right, it may be driver specific, but in my case I haven't changed blocking JNI driver. I have added ONLY one call to RXTX method mentioned in my previous post and blocking (as seen as from Java app) gone out... Maybe this is not elegant, but works without problem in my app. I am using only FTDI chips and their drivers from couple of years and maybe this is the kind of the way to have no many problems with serial as well? Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From andyrxtx at g0poy.co.uk Wed Feb 3 11:09:04 2010 From: andyrxtx at g0poy.co.uk (andyrxtx at g0poy.co.uk) Date: Wed, 3 Feb 2010 18:09:04 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes Message-ID: <20100203180904.164f24dd@workstation.site> ?Hello RXTX group, I have just joined this group, and this is my first posting. I wanted to pass on some information regarding rxtx, so apologies if this has been brought up before. I have searched back through the archives but nothing specific came up. I am not a Java programmer, and I only came across rxtx a few days ago. I use a piece of test equipment called a miniVNA http://www.miniradiosolutions.com/ This is a serial USB controlled instrument, and it has control software available for MS windows, and a very old and now non-working Linux application. A few days ago Dietmar, DL2SBA released a Java application to control the miniVNA, obviously this application makes use of rxtx. The program worked fine on Windows, so I set about installing it onto Linux. I use SUSE11.1 After a few false starts, I got the system running fairly easily, sorting out the file locking by adding the uucp group to the users account as suggested (I used the 2.2pre binary files) I then passed the install instructions onto another miniVNA user, who also uses SUSE, but he ran into problems. To cut a long story short, he was also having file lock problems, but the uucp fix did not work. Digging into his system I found that there have been some changes in SUSE 11.2. tty ports are now assigned to the dialout group rather than uucp. A hint in the rxtx INSTALL file, suggested that var/lock needs to be checked, so: SUSE 11.1, var/lock is root:uucp SUSE 11.2 var/lock is root:root A search on Google brought up several comments regarding this, and also a bugzilla entry. https://bugzilla.novell.com/show_bug.cgi?id=552095 However from reading the various posts, some of which are in the bugzilla entry, it appears that many distros may be, or have changed to this configuration, and this will undoubtedly break several things, rxtx included. I solved my fellow SUSE users problem by compiling the rxtx libs with the no lock file option during configure, and that solved his problem. As this issue will probably take some time to get resolved across all the various Linux distros, it might be worth considering changing the default on the Linux build of rxtx not to use lockfiles, or provide the two versions of the lib in the binary archive. Thanks for your indulgence Andy From damorales at gmail.com Wed Feb 3 11:33:23 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 15:33:23 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203180904.164f24dd@workstation.site> References: <20100203180904.164f24dd@workstation.site> Message-ID: Hi I had the same problem in Mandriva 2010 and yes, adding the user to the uucp group did not work as it used to be in earlier versions of linux distros, causing RXTX to not work as non root user. The problem appears because the existense of UDEV, now you MUST add a RULE so the group (uucp or whatever) have access (Read, Write, Execute) to the Serial Port. To solve the problem, without needing to recompile RXTX, you must add a rule to grant permissions (0666) to the group for the device or port (tty*, ttyUSB*, etc). I do not remember now what is the line i added but when i come back home i will give it to you (i am at work now). Greetings ! 2010/2/3 > Hello RXTX group, > > I have just joined this group, and this is my first posting. > I wanted to pass on some information regarding rxtx, so apologies if > this has been brought up before. I have searched back through the > archives but nothing specific came up. > > I am not a Java programmer, and I only came across rxtx a few days ago. > > I use a piece of test equipment called a miniVNA > http://www.miniradiosolutions.com/ > > This is a serial USB controlled instrument, and it has control software > available for MS windows, and a very old and now non-working Linux > application. > > A few days ago Dietmar, DL2SBA released a Java application to control the > miniVNA, obviously this application makes use of rxtx. > > The program worked fine on Windows, so I set about installing it onto > Linux. I use SUSE11.1 After a few false starts, I got the system running > fairly easily, sorting out the file locking by adding the uucp group to > the users account as suggested (I used the 2.2pre binary files) I then > passed the install instructions onto another miniVNA user, who also uses > SUSE, but he ran into problems. To cut a long story short, he was > also having file lock problems, but the uucp fix did not work. Digging > into his system I found that there have been some changes in SUSE 11.2. > > tty ports are now assigned to the dialout group rather than uucp. > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > checked, so: > > SUSE 11.1, var/lock is root:uucp > SUSE 11.2 var/lock is root:root > > A search on Google brought up several comments regarding this, and also > a bugzilla entry. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > However from reading the various posts, some of which are in the bugzilla > entry, it appears that many distros may be, or have changed to this > configuration, and this will undoubtedly break several things, rxtx > included. > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > no lock file option during configure, and that solved his problem. > > As this issue will probably take some time to get resolved across all the > various Linux distros, it might be worth considering changing the default > on the Linux build of rxtx not to use lockfiles, or provide the two > versions of the lib in the binary archive. > > Thanks for your indulgence > > Andy > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Wed Feb 3 12:07:02 2010 From: andy at g0poy.com (Andy Eskelson) Date: Wed, 3 Feb 2010 19:07:02 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> Message-ID: <20100203190702.1b0e7015@workstation.site> Thanks Daniel, I am aware of the permissions problem, I have had a udev rules to solve this for other programs for some time. . I don't think that this is the same problem. as far as I can understand things, the lock files are written in var/lock. Previously var/lock and dev/tty-whatever were the same group. Now with var/lock owned by and with a group of root:root anything other than root cannot create a lock file. Even minicom is broken by this change. This change is going to have quite a few knock-on effects I think. Andy On Wed, 3 Feb 2010 15:33:23 -0300 Daniel Morales Salas wrote: > Hi > > I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > group did not work as it used to be in earlier versions of linux distros, > causing RXTX to not work as non root user. > > The problem appears because the existense of UDEV, now you MUST add a RULE > so the group (uucp or whatever) have access (Read, Write, Execute) to the > Serial Port. > > To solve the problem, without needing to recompile RXTX, you must add a rule > to grant permissions (0666) to the group for the device or port (tty*, > ttyUSB*, etc). I do not remember now what is the line i added but when i > come back home i will give it to you (i am at work now). > > Greetings ! > > 2010/2/3 > > > Hello RXTX group, > > > > I have just joined this group, and this is my first posting. > > I wanted to pass on some information regarding rxtx, so apologies if > > this has been brought up before. I have searched back through the > > archives but nothing specific came up. > > > > I am not a Java programmer, and I only came across rxtx a few days ago. > > > > I use a piece of test equipment called a miniVNA > > http://www.miniradiosolutions.com/ > > > > This is a serial USB controlled instrument, and it has control software > > available for MS windows, and a very old and now non-working Linux > > application. > > > > A few days ago Dietmar, DL2SBA released a Java application to control the > > miniVNA, obviously this application makes use of rxtx. > > > > The program worked fine on Windows, so I set about installing it onto > > Linux. I use SUSE11.1 After a few false starts, I got the system running > > fairly easily, sorting out the file locking by adding the uucp group to > > the users account as suggested (I used the 2.2pre binary files) I then > > passed the install instructions onto another miniVNA user, who also uses > > SUSE, but he ran into problems. To cut a long story short, he was > > also having file lock problems, but the uucp fix did not work. Digging > > into his system I found that there have been some changes in SUSE 11.2. > > > > tty ports are now assigned to the dialout group rather than uucp. > > > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > checked, so: > > > > SUSE 11.1, var/lock is root:uucp > > SUSE 11.2 var/lock is root:root > > > > A search on Google brought up several comments regarding this, and also > > a bugzilla entry. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > However from reading the various posts, some of which are in the bugzilla > > entry, it appears that many distros may be, or have changed to this > > configuration, and this will undoubtedly break several things, rxtx > > included. > > > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > > no lock file option during configure, and that solved his problem. > > > > As this issue will probably take some time to get resolved across all the > > various Linux distros, it might be worth considering changing the default > > on the Linux build of rxtx not to use lockfiles, or provide the two > > versions of the lib in the binary archive. > > > > Thanks for your indulgence > > > > Andy > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From thisdyingdream at gmail.com Wed Feb 3 12:32:35 2010 From: thisdyingdream at gmail.com (Steven Harms) Date: Wed, 3 Feb 2010 14:32:35 -0500 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203190702.1b0e7015@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: This is currently a bug in OpenSUSE that affects more than just rxtx, and is a result of unified udev rules. You can work around this by making udev change the group back to uucp until something more happens. https://bugzilla.novell.com/show_bug.cgi?id=552095 Thanks, Steve On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > Thanks Daniel, > > I am aware of the permissions problem, I have had a udev rules to solve > this for other programs for some time. > . > I don't think that this is the same problem. as far as I can understand > things, the lock files are written in var/lock. Previously var/lock and > dev/tty-whatever were the same group. Now with var/lock owned by and with > a group of root:root anything other than root cannot create a lock > file. Even minicom is broken by this change. > > This change is going to have quite a few knock-on effects I think. > > > Andy > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > Daniel Morales Salas wrote: > >> Hi >> >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp >> group did not work as it used to be in earlier versions of linux distros, >> causing RXTX to not work as non root user. >> >> The problem appears because the existense of UDEV, now you MUST add a RULE >> so the group (uucp or whatever) have access (Read, Write, Execute) to the >> Serial Port. >> >> To solve the problem, without needing to recompile RXTX, you must add a rule >> to grant permissions (0666) to the group for the device or port (tty*, >> ttyUSB*, etc). I do not remember now what is the line i added but when i >> come back home i will give it to you (i am at work now). >> >> Greetings ! >> >> 2010/2/3 >> >> > Hello RXTX group, >> > >> > I have just joined this group, and this is my first posting. >> > I wanted to pass on ?some information regarding rxtx, so apologies if >> > this has been brought up before. I have searched back through the >> > archives but nothing specific came up. >> > >> > I am not a Java programmer, and I only came across rxtx a few days ago. >> > >> > I use a piece of test equipment called a miniVNA >> > http://www.miniradiosolutions.com/ >> > >> > This is a serial USB controlled instrument, and it has control software >> > available for MS windows, and a very old and now non-working Linux >> > application. >> > >> > A few days ago Dietmar, DL2SBA released a Java application to control the >> > miniVNA, obviously this application makes use of rxtx. >> > >> > The program worked fine on Windows, so I set about installing it onto >> > Linux. I use SUSE11.1 After a few false starts, I got the system running >> > fairly easily, sorting out the file locking by adding the uucp group to >> > the users account as suggested (I used the 2.2pre binary files) I then >> > passed the install instructions onto another miniVNA user, who also uses >> > SUSE, but he ran into problems. To cut a long story short, he was >> > also having file lock problems, but the uucp fix did not work. Digging >> > into his system I found that there have been some changes in SUSE 11.2. >> > >> > tty ports are now assigned to the dialout group rather than uucp. >> > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be >> > checked, so: >> > >> > SUSE 11.1, var/lock is root:uucp >> > SUSE 11.2 var/lock is root:root >> > >> > A search on Google brought up several comments regarding this, and also >> > a ?bugzilla entry. >> > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 >> > >> > However from reading the various posts, some of which are in the bugzilla >> > entry, it appears that many distros may be, or have changed to this >> > configuration, and this will undoubtedly break several things, rxtx >> > included. >> > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the >> > no lock file option during configure, and that solved his problem. >> > >> > As this issue will probably take some time to get resolved across all the >> > various Linux distros, it might be worth considering changing the default >> > on the Linux build of rxtx not to use lockfiles, or provide the two >> > versions of the lib in the binary archive. >> > >> > Thanks for your indulgence >> > >> > Andy >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> >> >> >> -- >> Atte: >> Daniel Dario Morales Salas >> Ingeniero Civil en Computaci?n e Inform?tica >> Tel?fono: 02 684 3417 >> Celular: 09 643 1802 >> Santiago, Chile > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 WWW: http://www.sharms.org/blog From andy at g0poy.com Wed Feb 3 17:58:29 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 00:58:29 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: <20100204005829.7dc944e1@workstation.site> Thanks Steve, changing the serial ports back the uucp is not a big problem. I have a udev rule that can be easily modified already. However I cannot see any way of dealing with the var/lock problem apart from making it writable to all. Any thoughts? Andy On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms wrote: > This is currently a bug in OpenSUSE that affects more than just rxtx, > and is a result of unified udev rules. You can work around this by > making udev change the group back to uucp until something more > happens. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > Thanks, > > Steve > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > Thanks Daniel, > > > > I am aware of the permissions problem, I have had a udev rules to solve > > this for other programs for some time. > > . > > I don't think that this is the same problem. as far as I can understand > > things, the lock files are written in var/lock. Previously var/lock and > > dev/tty-whatever were the same group. Now with var/lock owned by and with > > a group of root:root anything other than root cannot create a lock > > file. Even minicom is broken by this change. > > > > This change is going to have quite a few knock-on effects I think. > > > > > > Andy > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > Daniel Morales Salas wrote: > > > >> Hi > >> > >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > >> group did not work as it used to be in earlier versions of linux distros, > >> causing RXTX to not work as non root user. > >> > >> The problem appears because the existense of UDEV, now you MUST add a RULE > >> so the group (uucp or whatever) have access (Read, Write, Execute) to the > >> Serial Port. > >> > >> To solve the problem, without needing to recompile RXTX, you must add a rule > >> to grant permissions (0666) to the group for the device or port (tty*, > >> ttyUSB*, etc). I do not remember now what is the line i added but when i > >> come back home i will give it to you (i am at work now). > >> > >> Greetings ! > >> > >> 2010/2/3 > >> > >> > Hello RXTX group, > >> > > >> > I have just joined this group, and this is my first posting. > >> > I wanted to pass on ?some information regarding rxtx, so apologies if > >> > this has been brought up before. I have searched back through the > >> > archives but nothing specific came up. > >> > > >> > I am not a Java programmer, and I only came across rxtx a few days ago. > >> > > >> > I use a piece of test equipment called a miniVNA > >> > http://www.miniradiosolutions.com/ > >> > > >> > This is a serial USB controlled instrument, and it has control software > >> > available for MS windows, and a very old and now non-working Linux > >> > application. > >> > > >> > A few days ago Dietmar, DL2SBA released a Java application to control the > >> > miniVNA, obviously this application makes use of rxtx. > >> > > >> > The program worked fine on Windows, so I set about installing it onto > >> > Linux. I use SUSE11.1 After a few false starts, I got the system running > >> > fairly easily, sorting out the file locking by adding the uucp group to > >> > the users account as suggested (I used the 2.2pre binary files) I then > >> > passed the install instructions onto another miniVNA user, who also uses > >> > SUSE, but he ran into problems. To cut a long story short, he was > >> > also having file lock problems, but the uucp fix did not work. Digging > >> > into his system I found that there have been some changes in SUSE 11.2. > >> > > >> > tty ports are now assigned to the dialout group rather than uucp. > >> > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > >> > checked, so: > >> > > >> > SUSE 11.1, var/lock is root:uucp > >> > SUSE 11.2 var/lock is root:root > >> > > >> > A search on Google brought up several comments regarding this, and also > >> > a ?bugzilla entry. > >> > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > >> > > >> > However from reading the various posts, some of which are in the bugzilla > >> > entry, it appears that many distros may be, or have changed to this > >> > configuration, and this will undoubtedly break several things, rxtx > >> > included. > >> > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the > >> > no lock file option during configure, and that solved his problem. > >> > > >> > As this issue will probably take some time to get resolved across all the > >> > various Linux distros, it might be worth considering changing the default > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > >> > versions of the lib in the binary archive. > >> > > >> > Thanks for your indulgence > >> > > >> > Andy > >> > > >> > _______________________________________________ > >> > Rxtx mailing list > >> > Rxtx at qbang.org > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > >> > >> > >> > >> -- > >> Atte: > >> Daniel Dario Morales Salas > >> Ingeniero Civil en Computaci?n e Inform?tica > >> Tel?fono: 02 684 3417 > >> Celular: 09 643 1802 > >> Santiago, Chile > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > WWW: http://www.sharms.org/blog From damorales at gmail.com Wed Feb 3 18:26:38 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 22:26:38 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100204005829.7dc944e1@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: Hello I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva 2010 this is what i get: drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ and i don't have ANY problem with lock files and RXTX in my java software. All i had to do was add this rule to udev: # serial KERNEL=="tty*", GROUP="uucp", MODE="0666" and that was all. Of course my user (metalklesk) is part of uucp group. I did not make /var/lock writable to all users. Greetings ! 2010/2/3 Andy Eskelson > Thanks Steve, > > changing the serial ports back the uucp is not a big problem. I have a > udev rule that can be easily modified already. However I cannot see any > way of dealing with the var/lock problem apart from making it writable to > all. Any thoughts? > > Andy > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > wrote: > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > and is a result of unified udev rules. You can work around this by > > making udev change the group back to uucp until something more > > happens. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > Thanks, > > > > Steve > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > Thanks Daniel, > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > this for other programs for some time. > > > . > > > I don't think that this is the same problem. as far as I can understand > > > things, the lock files are written in var/lock. Previously var/lock and > > > dev/tty-whatever were the same group. Now with var/lock owned by and > with > > > a group of root:root anything other than root cannot create a lock > > > file. Even minicom is broken by this change. > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > Daniel Morales Salas wrote: > > > > > >> Hi > > >> > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > the uucp > > >> group did not work as it used to be in earlier versions of linux > distros, > > >> causing RXTX to not work as non root user. > > >> > > >> The problem appears because the existense of UDEV, now you MUST add a > RULE > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > the > > >> Serial Port. > > >> > > >> To solve the problem, without needing to recompile RXTX, you must add > a rule > > >> to grant permissions (0666) to the group for the device or port (tty*, > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > i > > >> come back home i will give it to you (i am at work now). > > >> > > >> Greetings ! > > >> > > >> 2010/2/3 > > >> > > >> > Hello RXTX group, > > >> > > > >> > I have just joined this group, and this is my first posting. > > >> > I wanted to pass on some information regarding rxtx, so apologies > if > > >> > this has been brought up before. I have searched back through the > > >> > archives but nothing specific came up. > > >> > > > >> > I am not a Java programmer, and I only came across rxtx a few days > ago. > > >> > > > >> > I use a piece of test equipment called a miniVNA > > >> > http://www.miniradiosolutions.com/ > > >> > > > >> > This is a serial USB controlled instrument, and it has control > software > > >> > available for MS windows, and a very old and now non-working Linux > > >> > application. > > >> > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > control the > > >> > miniVNA, obviously this application makes use of rxtx. > > >> > > > >> > The program worked fine on Windows, so I set about installing it > onto > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > running > > >> > fairly easily, sorting out the file locking by adding the uucp group > to > > >> > the users account as suggested (I used the 2.2pre binary files) I > then > > >> > passed the install instructions onto another miniVNA user, who also > uses > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > >> > also having file lock problems, but the uucp fix did not work. > Digging > > >> > into his system I found that there have been some changes in SUSE > 11.2. > > >> > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > >> > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > >> > checked, so: > > >> > > > >> > SUSE 11.1, var/lock is root:uucp > > >> > SUSE 11.2 var/lock is root:root > > >> > > > >> > A search on Google brought up several comments regarding this, and > also > > >> > a bugzilla entry. > > >> > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > >> > > > >> > However from reading the various posts, some of which are in the > bugzilla > > >> > entry, it appears that many distros may be, or have changed to this > > >> > configuration, and this will undoubtedly break several things, rxtx > > >> > included. > > >> > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > with the > > >> > no lock file option during configure, and that solved his problem. > > >> > > > >> > As this issue will probably take some time to get resolved across > all the > > >> > various Linux distros, it might be worth considering changing the > default > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > >> > versions of the lib in the binary archive. > > >> > > > >> > Thanks for your indulgence > > >> > > > >> > Andy > > >> > > > >> > _______________________________________________ > > >> > Rxtx mailing list > > >> > Rxtx at qbang.org > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > >> > > > >> > > >> > > >> > > >> -- > > >> Atte: > > >> Daniel Dario Morales Salas > > >> Ingeniero Civil en Computaci?n e Inform?tica > > >> Tel?fono: 02 684 3417 > > >> Celular: 09 643 1802 > > >> Santiago, Chile > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at qbang.org > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > -- > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > WWW: http://www.sharms.org/blog > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Thu Feb 4 05:31:46 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 12:31:46 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: <20100204123146.6cffeb67@workstation.site> Thank's for the confirmation. Something odd is going on somewhere in SUSE 11.2. I'll have to build up a local SUSE11.2 system to see if I can nail down exactly what is going on. Something is blocking the lockfiles in var/lock. The net is nice, but it's a bit difficult trying to work out what is going on what the machine in question is in Germany and I'm in the UK :-) Andy On Wed, 3 Feb 2010 22:26:38 -0300 Daniel Morales Salas wrote: > Hello > > I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva > 2010 this is what i get: > > drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ > > and i don't have ANY problem with lock files and RXTX in my java software. > All i had to do was add this rule to udev: > > # serial > KERNEL=="tty*", GROUP="uucp", MODE="0666" > > and that was all. Of course my user (metalklesk) is part of uucp group. > I did not make /var/lock writable to all users. > > Greetings ! > > 2010/2/3 Andy Eskelson > > > Thanks Steve, > > > > changing the serial ports back the uucp is not a big problem. I have a > > udev rule that can be easily modified already. However I cannot see any > > way of dealing with the var/lock problem apart from making it writable to > > all. Any thoughts? > > > > Andy > > > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > > wrote: > > > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > > and is a result of unified udev rules. You can work around this by > > > making udev change the group back to uucp until something more > > > happens. > > > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > > > Thanks, > > > > > > Steve > > > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > > Thanks Daniel, > > > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > > this for other programs for some time. > > > > . > > > > I don't think that this is the same problem. as far as I can understand > > > > things, the lock files are written in var/lock. Previously var/lock and > > > > dev/tty-whatever were the same group. Now with var/lock owned by and > > with > > > > a group of root:root anything other than root cannot create a lock > > > > file. Even minicom is broken by this change. > > > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > > Daniel Morales Salas wrote: > > > > > > > >> Hi > > > >> > > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > > the uucp > > > >> group did not work as it used to be in earlier versions of linux > > distros, > > > >> causing RXTX to not work as non root user. > > > >> > > > >> The problem appears because the existense of UDEV, now you MUST add a > > RULE > > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > > the > > > >> Serial Port. > > > >> > > > >> To solve the problem, without needing to recompile RXTX, you must add > > a rule > > > >> to grant permissions (0666) to the group for the device or port (tty*, > > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > > i > > > >> come back home i will give it to you (i am at work now). > > > >> > > > >> Greetings ! > > > >> > > > >> 2010/2/3 > > > >> > > > >> > Hello RXTX group, > > > >> > > > > >> > I have just joined this group, and this is my first posting. > > > >> > I wanted to pass on some information regarding rxtx, so apologies > > if > > > >> > this has been brought up before. I have searched back through the > > > >> > archives but nothing specific came up. > > > >> > > > > >> > I am not a Java programmer, and I only came across rxtx a few days > > ago. > > > >> > > > > >> > I use a piece of test equipment called a miniVNA > > > >> > http://www.miniradiosolutions.com/ > > > >> > > > > >> > This is a serial USB controlled instrument, and it has control > > software > > > >> > available for MS windows, and a very old and now non-working Linux > > > >> > application. > > > >> > > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > > control the > > > >> > miniVNA, obviously this application makes use of rxtx. > > > >> > > > > >> > The program worked fine on Windows, so I set about installing it > > onto > > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > > running > > > >> > fairly easily, sorting out the file locking by adding the uucp group > > to > > > >> > the users account as suggested (I used the 2.2pre binary files) I > > then > > > >> > passed the install instructions onto another miniVNA user, who also > > uses > > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > > >> > also having file lock problems, but the uucp fix did not work. > > Digging > > > >> > into his system I found that there have been some changes in SUSE > > 11.2. > > > >> > > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > > >> > > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > > >> > checked, so: > > > >> > > > > >> > SUSE 11.1, var/lock is root:uucp > > > >> > SUSE 11.2 var/lock is root:root > > > >> > > > > >> > A search on Google brought up several comments regarding this, and > > also > > > >> > a bugzilla entry. > > > >> > > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > >> > > > > >> > However from reading the various posts, some of which are in the > > bugzilla > > > >> > entry, it appears that many distros may be, or have changed to this > > > >> > configuration, and this will undoubtedly break several things, rxtx > > > >> > included. > > > >> > > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > > with the > > > >> > no lock file option during configure, and that solved his problem. > > > >> > > > > >> > As this issue will probably take some time to get resolved across > > all the > > > >> > various Linux distros, it might be worth considering changing the > > default > > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > > >> > versions of the lib in the binary archive. > > > >> > > > > >> > Thanks for your indulgence > > > >> > > > > >> > Andy > > > >> > > > > >> > _______________________________________________ > > > >> > Rxtx mailing list > > > >> > Rxtx at qbang.org > > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > > >> > > > > >> > > > >> > > > >> > > > >> -- > > > >> Atte: > > > >> Daniel Dario Morales Salas > > > >> Ingeniero Civil en Computaci?n e Inform?tica > > > >> Tel?fono: 02 684 3417 > > > >> Celular: 09 643 1802 > > > >> Santiago, Chile > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at qbang.org > > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > > > -- > > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > > > WWW: http://www.sharms.org/blog > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From Bob_Jacobsen at lbl.gov Thu Feb 4 09:26:49 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Thu, 4 Feb 2010 08:26:49 -0800 Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 Message-ID: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're using RXTX-2.2pre2, although it emits the known message about "Version mismatch". WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 After the usual messing around, we've got it working on 11 Windows versions, multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ have things working rarely say so, so I don't know whether anybody has gotten it to work on 10.4 or not. The problem encountered is this: dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib dyld: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib followed by the JVM crashing hard. I've got those dump files if that would help. Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If so, is there a patch I can get and build? Thanks Bob -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From tjarvi at qbang.org Thu Feb 4 14:22:21 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 4 Feb 2010 14:22:21 -0700 (MST) Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 In-Reply-To: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> References: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> Message-ID: On Thu, 4 Feb 2010, Bob Jacobsen wrote: > We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're > using RXTX-2.2pre2, although it emits the known message about "Version > mismatch". > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > > After the usual messing around, we've got it working on 11 Windows versions, > multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with > a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ > have things working rarely say so, so I don't know whether anybody has gotten > it to work on 10.4 or not. > > The problem encountered is this: > > dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > dyld: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > followed by the JVM crashing hard. I've got those dump files if that would > help. > > Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If > so, is there a patch I can get and build? > Hi Bob, I talked to a coworker about the problem you ran into. It appears that it is possible to target 'older' Mac systems through makefile configuration changes. "Configuring a Makefile-Based Project If you have a makefile-based project, you can also take advantage of SDK-based development, by adding the appropriate options to your compile and link commands. Using SDKs in makefile-based projects requires GCC 4.0 or later. To choose an SDK, you use the -isysroot option with the compiler and the -syslibroot option with the linker. Both options require that you specify the full path to the desired SDK directory. To set the Deployment OS version in a makefile, use a makefile variable of the form: ENVP= MACOSX_DEPLOYMENT_TARGET=10.4. To use this variable in your makefile, include it in front of your compile and link commands." http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html Or build on the oldest system you want to support. -- Trent Jarvi tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Thu Feb 4 14:56:19 2010 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Thu, 4 Feb 2010 14:56:19 -0700 Subject: [Rxtx] RXTX on 64 Bit Redhat In-Reply-To: References: <4ec9eab61001281448g3dd84910r867619948a4e0d7a@mail.gmail.com> Message-ID: Trent -- Finally fixed all my build related issues. I ran into another issue. On one of my machines my JDK is returning multiple folders for the "java.ext.dirs" (java.ext.dirs -> /opt/jdk1.6.0_17/jre/lib/ext:/usr/java/packages/lib/ext) system property. As a result my JVM wasn't able to detect the gnu.io.rxtx.properties. I am attaching a patch for RXTXCommDriver.java file to check for multiple locations. Also i have to assign permission 660 to all my dev ports to be located by RXTX. Pawan ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 5:12 PM To: Trent Jarvi Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Here is the error i get when i build the src from release-2-1-7 -bash-3.2$ make ( \ \ cd i686-pc-linux-gnu; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/ jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I/opt/jav a1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec - c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialImp.lo;\ if [ "Serial" = "Serial" ]; then \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I /opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_tim espec -c /home/jb_stg/rxtx/rxtx-devel/./src/fuserImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ else \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo; \ fi; \ ) gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/inclu de -I/opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need _timespec -c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -fPIC -DPIC -o /hom e/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/.libs/SerialImp.o /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:25:29: error: gnu_io_RXTXPort.h: No such file or directory In file included from /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:113: /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:91: error: expected specifier-qua lifier-list before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'jobject' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:408: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:409: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:410: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:411: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:415: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:416: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:417: error: expected '=', ',', '; ', 'asm' or '__attribute__' before 'is_interrupted' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:418: error: expected declaration specifiers or '...' before 'jint' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:424: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:441: error: expected ')' before ' *' token ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 4:57 PM To: Santosh Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Santosh -- Thank you. That fixed the issue. All -- What CVS branch or release should i use to get the latest RXTX src code. Pawan ________________________________ From: Santosh [mailto:santosh.ry at gmail.com] Sent: Thursday, January 28, 2010 3:49 PM To: Kharbanda, Pawan Cc: Trent Jarvi; rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat error "./configure: /bin/sh^M: bad interpreter: No such file or directory". I think you need to run dos2unix on script files before compiling. Thanks, Santosh On Thu, Jan 28, 2010 at 5:33 PM, Kharbanda, Pawan > wrote: Trent -- We are upgrading our exisiting OS and JDK on a project that rely heavily on RXTX api's. We are now using JDK1.6 32 bit (build 1.6.0_17-b04) and RedHat 5 on a 64 bit machine. Linux tocrhstg02.dot.state.co.us 2.6.18-164.6.1.el5 #1 SMP Tue Oct 27 11:30:06 EDT 2009 i686 i686 i386 GNU/Linux Red Hat Enterprise Linux Server release 5.4 (Tikanga) I tried to run version 2.1.7 r2 on it but not able to see any of my Digi ports I was able to access only /dev/ttyS0 (physical ports). Not sure if the problem is with the Digi driver or RXTX. I tried to open a Digi port with minicom and it worked fine. I also tried to get latest from CVS (rxtx-devel) and when I do "configure" I see this error "./configure: /bin/sh^M: bad interpreter: No such file or directory". Can someone please help me with this? Thanks for the help. Pawan _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch.txt URL: From juan.vicente.l.g at gmail.com Sat Feb 13 04:44:17 2010 From: juan.vicente.l.g at gmail.com (Juan Vicente Lopez Gutierrez) Date: Sat, 13 Feb 2010 12:44:17 +0100 Subject: [Rxtx] RXTX in macmini OSX 10.5 Message-ID: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> Hello. My name is Juanvi and I'm from Spain. I tried to launch a software created by me in the library CXR java to send information through the serial port and I can not make it work. In windows if I've done but not mac. I have a mac mini with OSX 10.5 and have read in the list of web mail that you CXR if you have managed to make it work on that operating system. I need you help me please. Do I make the mistake that shows me java: run: Stable Library =============================== Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 gnu.io.PortInUseException: Unknow Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:26) at TwoWatSerialComm.main(TwoWaySerialComm.java:106) Experimental: JNI_OnLoad called. GENERACION CORRECTA (total time: 0 seconds) I do not have permission to access the serial port, do not know. Os agradeceria much to sit down. A greeting and thanks. Pardon my English. Juanvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From juan.vicente.l.g at gmail.com Sat Feb 13 14:39:41 2010 From: juan.vicente.l.g at gmail.com (Juan Vicente Lopez Gutierrez) Date: Sat, 13 Feb 2010 22:39:41 +0100 Subject: [Rxtx] Fwd: RXTX in macmini OSX 10.5 In-Reply-To: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> References: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> Message-ID: <29405e5c1002131339m2059d169sdc8549ed9706a1af@mail.gmail.com> ---------- Forwarded message ---------- From: Juan Vicente Lopez Gutierrez Date: 2010/2/13 Subject: RXTX in macmini OSX 10.5 To: rxtx at qbang.org Hello. My name is Juanvi and I'm from Spain. I tried to launch a software created by me in the library CXR java to send information through the serial port and I can not make it work. In windows if I've done but not mac. I have a mac mini with OSX 10.5 and have read in the list of web mail that you CXR if you have managed to make it work on that operating system. I need you help me please. Do I make the mistake that shows me java: run: Stable Library =============================== Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 gnu.io.PortInUseException: Unknow Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:26) at TwoWatSerialComm.main(TwoWaySerialComm.java:106) Experimental: JNI_OnLoad called. GENERACION CORRECTA (total time: 0 seconds) I do not have permission to access the serial port, do not know. Os agradeceria much to sit down. A greeting and thanks. Pardon my English. Juanvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Mon Feb 22 04:35:48 2010 From: george.dma at gmail.com (George H) Date: Mon, 22 Feb 2010 13:35:48 +0200 Subject: [Rxtx] Lingering rxtx process Message-ID: Hi, I am using RXTX v2.1-7. I use it to communicate with 2 serial receipt printers and 1 serial line display device. My program runs well using the RXTX library on Windows and Linux. But... when I installed Linux on another hardware the program does not exit properly. By this I mean that the java program seems to have exited (passed the System.exit(0)) code but the console still does not return to the bash shell. I have to CTRL+C each time to kill the program. And on each restart RXTX has to remove stale LCK files. Just note I am only getting this on one machine, if it makes any difference it is an i686 system with all VIA chipsets and VIA-C7M NannoBGA2 processor. Any ideas? Thanks -- George H george.dma at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Mon Feb 22 04:43:43 2010 From: george.dma at gmail.com (George H) Date: Mon, 22 Feb 2010 13:43:43 +0200 Subject: [Rxtx] Lingering rxtx process Message-ID: Hi, I am using RXTX v2.1-7. I use it to communicate with 2 serial receipt printers and 1 serial line display device. My program runs well using the RXTX library on Windows and Linux. But... when I installed Linux on another hardware the program does not exit properly. By this I mean that the java program seems to have exited (passed the System.exit(0)) code but the console still does not return to the bash shell. I have to CTRL+C each time to kill the program. And on each restart RXTX has to remove stale LCK files. Just note I am only getting this on one machine, if it makes any difference it is an i686 system with all VIA chipsets and VIA-C7M NannoBGA2 processor. Any ideas? Thanks -- George H george.dma at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Tue Feb 23 01:29:42 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Tue, 23 Feb 2010 09:29:42 +0100 Subject: [Rxtx] Lingering rxtx process In-Reply-To: References: Message-ID: <73a89f361002230029w4a9ec14bt56d654e43c1c9623@mail.gmail.com> 2010/2/22 George H > Hi, > > I am using RXTX v2.1-7. > I use it to communicate with 2 serial receipt printers and 1 serial line > display device. My program runs well using the RXTX library on Windows and > Linux. > But... when I installed Linux on another hardware the program does not exit > properly. By this I mean that the java program seems to have exited (passed > the System.exit(0)) code but the console still does not return to the bash > shell. > > Thread in Noember 2009' - http://mailman.qbang.org/pipermail/rxtx/2009-November/5778408.html I have disocvered one technique which solved this problem in Linux Ubuntu and Mac for RXTX pre2.2, but should helps in 2.1.7 as well. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Thu Feb 25 02:41:46 2010 From: george.dma at gmail.com (George H) Date: Thu, 25 Feb 2010 11:41:46 +0200 Subject: [Rxtx] Lingering rxtx process In-Reply-To: <73a89f361002230029w4a9ec14bt56d654e43c1c9623@mail.gmail.com> References: <73a89f361002230029w4a9ec14bt56d654e43c1c9623@mail.gmail.com> Message-ID: With Mariusz Dec help and with the help of the threads that were mentioned http://mailman.qbang.org/pipermail/rxtx/2009-November/5790326.html http://embeddedfreak.wordpress.com/2008/10/08/rxtx-serial-port-helper/ I managed to solved my problem. I didn't really like it so much. I am not using the InputStream.read(byte[], int, int) method as for me I can break out of reading the stream if I get a '\n' or a 0x00. Either way the below code sample works for me. int data = 0; int len = 0; while(true) { data = commReader.getInputStream().read(); if(data == -1 || data == 0x00 || data == '\n' || commReader.getInputStream().available() < 1) { break; } if(len == buffer.length) { processData(buffer); clearBuffer(); } buffer[len++] = (byte)data; } Before I would loop the while until data != -1. But that blocks on .close() and my program never gets to exit. Adding .available() < 1 as a break condition fixes it when I call .close() I am going to see if this is a linux kernel configuration issue or not cos it isn't so obvious and I hardly ever use .available() when reading streams. Love the project though :) -- George H george.dma at gmail.com On Tue, Feb 23, 2010 at 10:29 AM, Mariusz Dec wrote: > > > 2010/2/22 George H > > Hi, >> >> I am using RXTX v2.1-7. >> I use it to communicate with 2 serial receipt printers and 1 serial line >> display device. My program runs well using the RXTX library on Windows and >> Linux. >> But... when I installed Linux on another hardware the program does not >> exit properly. By this I mean that the java program seems to have exited >> (passed the System.exit(0)) code but the console still does not return to >> the bash shell. >> >> Thread in Noember 2009' - > > http://mailman.qbang.org/pipermail/rxtx/2009-November/5778408.html > > I have disocvered one technique which solved this problem in Linux Ubuntu > and Mac for RXTX pre2.2, but should helps in 2.1.7 as well. > > Regards > Mariusz > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 01:02:21 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 13:32:21 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> My serial port driver(apparently) does not support receive timeout.I registered an event listener for DATA_AVAILABLE. However, the control never seems to come out of the 'while' loop.Shouldn't the InputStream.read return a '-1' immediately if no data is available (this seems to be the default operation)? This was tried on a x86 Linux desktop using rxtx-2.1-7 I've added the snippet for clarity: /******************************************************************************************************************************************************************************/ mySerialPort.enableReceiveThreshold(2000);//Trying to set a time limit for read calls System.out.println(mySerialPort.isReceiveTimeoutEnabled()); // I get FALSE, so its not supported on hardware. mySerialPort.addEventListener(this); mySerialPort.notifyOnDataAvailable(true);//register a event with //my SerialEvent listener implementation: public void serialEvent(SerialPortEvent arg0) { int newData=0; switch(arg0.getEventType()){ case SerialPortEvent.DATA_AVAILABLE: while (newData != -1) { try { newData = is.read();//This should eventually return a -1 if no data is available within a timeout.PROBLEM!! System.out.println("Got a byte from port:"+newData); if (newData == -1) { break; } } catch (IOException ex) { System.err.println(ex); return; } } break; } return; } /******************************************************************************************************************************************************************************/ Thanks and regards, Ravi From michael.erskine at ketech.com Wed Feb 3 02:26:50 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 09:26:50 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From michael.erskine at ketech.com Wed Feb 3 05:03:30 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 12:03:30 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > Michael Erskine > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > > Your event handler should handle the event and return immediately so that its > controlling thread can handle other events. I recommend a single read in the > following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) > reads all available bytes up to the size of the buffer returning the number of > bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } After posting this I considered the glaring possibility of the rawbuf read buffer being too small to receive all the available bytes and perhaps skipping data: after all, I'm guessing that is why we see so many posts asking for help with blocking implementations of read event handlers looping on "while(bytes are available)". I've spent this morning writing an extensive multi-threaded unit test suite that includes tests with a tiny buffer compared to the amount of data available and found that no data was being skipped. I now want to know why! The SerialPortEvent.DATA_AVAILABLE event must be being fired again if there is more data available on the input stream. If that is the case then it should be heavily documented with good examples in the wiki to avoid the types of developer anguish we see so regularly. BTW: I'm not at liberty to post the JUnit tests as they use my company's unit test suite framework. Regards, Michael Erskine. From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 06:18:04 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 18:48:04 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Hello Michael, I tried out your suggestion but the problem is that the read(rawbuf) blocks until the entire length of the rawbuf array has been read (blocking). I cannot decide on a reasonable size of the array because it varies from 2 bytes to as much as 50 byes (i'm communicating with a modem,each response is of a different length), which is why i wanted to use non blocking calls. But on a side note, read(byte[]) in turn calls the read() in a loop.In the native C function, the read is supposed to return a -1 upon timeout.But my driver does not support timeout.The default timeout value is zero and the linux select call upon zero time out causes an infinite wait.What am i missing...... Thanks and regards, Ravi Date: Wed, 3 Feb 2010 09:26:50 +0000 From: Michael Erskine To: "rxtx at qbang.org" Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: Content-Type: text/plain; charset="us-ascii" > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From m.kirkland at comcast.net Wed Feb 3 06:46:03 2010 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 3 Feb 2010 05:46:03 -0800 Subject: [Rxtx] One port blocking another port In-Reply-To: References: Message-ID: <68768633814F4D7D86761D34F0764FE0@bengal.net> It turns out this is caused by having the RTS/CTS flow control turned on and me not providing a true on the RTS pin. Somehow it seems the port timing out on a read allows the write to proceed. This is not an issue for my application but I wonder if the write should not proceed until the RTS pin is true even if a read times out. mk -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Monday, January 25, 2010 7:48 PM To: Mike Kirkland Cc: rxtx at qbang.org Subject: Re: [Rxtx] One port blocking another port On Mon, 25 Jan 2010, Mike Kirkland wrote: > > Hi All, > > ? > > I have a program that reads from one com port and writes to another com > port. It also does the same thing in reverse (reads from the second com port > and writes to the first one. It basically ties two com ports together. > > ? > > One port is very chatty and has a consent stream of data. The other port has > very little data. > > ? > > Both ports use a 5000 ms (5 second) time out. > > ? > > The issue I am having is that is appears that the first port?s write to the > second port is blocked while the second port is waiting for input. The first > port?s write proceeds only after the second port has timed out. > > ? > > I suppose I could have something twisted around in my code but I was > wondering if this is a know issue? > Hi Kirk, I've not seen a report like this. Perhaps some simple reproduction code will reveal a problem on your end or help us identify a problem in rxtx. I think there are several users doing multiport communication. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Wed Feb 3 07:03:58 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:03:58 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Message-ID: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> 2010/2/3 Ravishankar N > Hello Michael, > [..] > But on a side note, read(byte[]) in turn calls the read() in a loop.In the > native C function, the read is supposed to return a -1 upon timeout.But my > driver > does not support timeout.The default timeout value is zero and the linux > select call upon zero time out causes an infinite wait.What am i > missing...... > > When I have tested RXTX between platforms, I have observed "hangup" inside JNI driver when no data in Linux, is normal thing. Solution was setting the timeout for RXTX when no data from JNI driver. Something like that: commPort.enableReceiveTimeout(10); And it works perfect.... The only difference is that I am NOT using events - I am using continous read in separate thread and if data is available, is parsed and transferred to application using exception. Regards Mariusz > Thanks and regards, > Ravi > > Date: Wed, 3 Feb 2010 09:26:50 +0000 > From: Michael Erskine > To: "rxtx at qbang.org" > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > Message-ID: > > > Content-Type: text/plain; charset="us-ascii" > > > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of > > Ravishankar N > > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > > > My serial port driver(apparently) does not support receive timeout.I > > registered an event listener for DATA_AVAILABLE. However, the control > never > > seems to come out of the 'while' loop.Shouldn't the > > InputStream.read return a '-1' immediately if no data is available (this > seems > > to be the default operation)? > > Your event handler should handle the event and return immediately so that > its controlling thread can handle other events. I recommend a single read in > the following manner: rawbuf is a byte[] of "reasonable" size and the > read(byte[]) reads all available bytes up to the size of the buffer > returning the number of bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } > > This style of reading has worked for me with RXTX on Linux and Windows XP > for a good few years now in railway industry communications systems. Any > timeouts (largely unnecessary in my applications) can be handled elsewhere, > usually at a higher layer. > > Regards, > Michael Erskine. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Feb 3 07:22:55 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 3 Feb 2010 09:22:55 -0500 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: I'm guessing that this is driver specific. I recently had to support a select()/poll() infrastructure for a linux serial DD, its certainly non trivial to support async IO, so I suspect the problem in this case has to do with missing poll infrastructure in the device driver. This also has to coupled with special open flags for the device (which is within the rxtx code) The key routines within a 2.6 kernel linux device driver are shown below (if you have access to it for your particular device) are indicated below (here is a snippet from my device driver c code that supports polling/select). User space code to test this shown below also, note that the device needs to be opened with the O_NONBLOCK option to support the select/poll api // device driver code ..... /* * File operations supported by this driver. */ static struct file_operations iop_fops = { .owner = THIS_MODULE, .check_flags= iop_check_flags, .ioctl = iop_ioctl, .open = iop_open, .poll = iop_poll, // SUPPORT FOR SELECT/POLL infrastructure .read = iop_read, .release = iop_release, .write = iop_write, }; /** * Select/poll/epoll infrastructure. * * @param file * @param wait * * @return */ static unsigned int iop_poll(struct file *filp, poll_table *wait) { struct iop_device *devp = (struct iop_device *)filp->private_data; // the poll_table wait arg is an opaque pointer poll_wait(filp, &devp->readq, wait); // return from poll indicating whether we have read/write data unsigned int mask = 0; if (kfifo_len(devp->rx_fifo)) { mask |= (POLLIN | POLLRDNORM); } // @JC We don't do select on write yet // if (kfifo_len(devp->tx_fifo)) { // mask |= (POLLOUT | POLLWRNORM); // } // Only print out while debugging // if (mask != 0) { // printk (KERN_INFO "%s: [%04x]\n", __FUNCTION__, mask); // } return mask; } /** * device driver blocking and non blocking read function. This * function reads the requested number of bytes from the read * kfifo blocking as required. * * @param filp * @param buf * @param count * @param f_pos * * @return */ static ssize_t iop_read(struct file *filp, char __user *buf, size_t count, loff_t * ppos) { // access appropriate device struct struct iop_device *devp = (struct iop_device *) filp->private_data; ssize_t retval; // support non blocking mode (default) by checking if the kfifo is empty first if ((kfifo_len(devp->rx_fifo)==0) && (filp->f_flags & O_NONBLOCK)) { return -EAGAIN; } // wait for rx_fifo to receive data via receive interrupts retval = wait_event_interruptible(devp->readq, kfifo_len(devp->rx_fifo) != 0); // check for some error condition if (retval) { printk (KERN_ERR "%s: wait_event_interruptible returned[%d]\n", __FUNCTION__, retval); return retval; } // copy max requested bytes from rx_fifo to device buffer // this may still leave bytes in the kfifo for a subsequent read // if we are reading in a loop retval = kfifo_get(devp->rx_fifo, devp->rxbuf, count); // printk (KERN_INFO "%s: [%d] byte(s)\n", __FUNCTION__, retval); if (copy_to_user(buf, devp->rxbuf, retval)) { printk (KERN_ERR "%s: problem copying rx_fifo data to user buffer\n", __FUNCTION__); return -EFAULT; } return retval; } // a selection of my user space code reading via select()/poll()..... // user space open code iop_fd = ::open( deviceName.data(), O_RDWR | O_NONBLOCK); while ((bytes_to_expect - bytes_read) > 0) { // must reinitialize these between select calls fd_set readfds; FD_ZERO( &readfds ); FD_SET( iop_fd, &readfds ); // 1s sec read polling timeout struct timeval timeout; timeout.tv_sec = 1; timeout.tv_usec = 0; int rc = select( FD_SETSIZE, &readfds, NULL, NULL, &timeout ); // read from file when descriptor // indicates data available without blocking if ((rc > 0) && FD_ISSET(iop_fd, &readfds)) { // read into the appropriate offset within the rx_buf int temp = read(iop_fd, rx_buf + bytes_read, bytes_to_expect - bytes_read); if (!temp) { printf("EOF detected with %d bytes expected\n", bytes_to_expect - bytes_read); } else { bytes_read += temp; } } else if (rc < 0){ printf("%s: select on [%s], bytes_read[%d], errno=%d\n", __FUNCTION__, thread_args->device, bytes_read, errno); } else { printf("%s: select on [%s], bytes_read[%d], timeout\n", __FUNCTION__, thread_args->device, bytes_read); } } On Wed, Feb 3, 2010 at 9:03 AM, Mariusz Dec wrote: > > > 2010/2/3 Ravishankar N > >> Hello Michael, >> [..] >> >> But on a side note, read(byte[]) in turn calls the read() in a loop.In the >> native C function, the read is supposed to return a -1 upon timeout.But my >> driver >> does not support timeout.The default timeout value is zero and the linux >> select call upon zero time out causes an infinite wait.What am i >> missing...... >> >> > When I have tested RXTX between platforms, I have observed "hangup" inside > JNI driver when no data in Linux, is normal thing. > > Solution was setting the timeout for RXTX when no data from JNI driver. > > Something like that: > > commPort.enableReceiveTimeout(10); > > And it works perfect.... > > The only difference is that I am NOT using events - I am using continous > read in separate thread and if data is available, is parsed and transferred > to application using exception. > > Regards > Mariusz > > > >> Thanks and regards, >> Ravi >> >> Date: Wed, 3 Feb 2010 09:26:50 +0000 >> From: Michael Erskine >> To: "rxtx at qbang.org" >> Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? >> Message-ID: >> >> >> Content-Type: text/plain; charset="us-ascii" >> >> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >> Of >> > Ravishankar N >> > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? >> > >> > My serial port driver(apparently) does not support receive timeout.I >> > registered an event listener for DATA_AVAILABLE. However, the control >> never >> > seems to come out of the 'while' loop.Shouldn't the >> > InputStream.read return a '-1' immediately if no data is available (this >> seems >> > to be the default operation)? >> >> Your event handler should handle the event and return immediately so that >> its controlling thread can handle other events. I recommend a single read in >> the following manner: rawbuf is a byte[] of "reasonable" size and the >> read(byte[]) reads all available bytes up to the size of the buffer >> returning the number of bytes actually read... >> >> case SerialPortEvent.DATA_AVAILABLE: >> try { >> int i = is.read(rawbuf); >> if (i == -1) { >> << process EOF condition - should never happen >> >> return; >> } >> << process bytes (rawbuf, i); >> >> return; >> } catch (IOException e) { >> << promptly deal with exception >> >> return; >> } >> >> This style of reading has worked for me with RXTX on Linux and Windows XP >> for a good few years now in railway industry communications systems. Any >> timeouts (largely unnecessary in my applications) can be handled elsewhere, >> usually at a higher layer. >> >> Regards, >> Michael Erskine. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Feb 3 07:33:27 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:33:27 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: <73a89f361002030633j682610afia48dc7accd8e049b@mail.gmail.com> 2010/2/3 John Coffey > I'm guessing that this is driver specific. I recently had to support a > select()/poll() infrastructure for a linux serial DD, its certainly non > trivial to support async IO, so I suspect the problem in this case has to do > with missing poll infrastructure in the device driver. This also has to > coupled with special open flags for the device (which is within the rxtx > code) > > Yes, you are right, it may be driver specific, but in my case I haven't changed blocking JNI driver. I have added ONLY one call to RXTX method mentioned in my previous post and blocking (as seen as from Java app) gone out... Maybe this is not elegant, but works without problem in my app. I am using only FTDI chips and their drivers from couple of years and maybe this is the kind of the way to have no many problems with serial as well? Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From andyrxtx at g0poy.co.uk Wed Feb 3 11:09:04 2010 From: andyrxtx at g0poy.co.uk (andyrxtx at g0poy.co.uk) Date: Wed, 3 Feb 2010 18:09:04 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes Message-ID: <20100203180904.164f24dd@workstation.site> ?Hello RXTX group, I have just joined this group, and this is my first posting. I wanted to pass on some information regarding rxtx, so apologies if this has been brought up before. I have searched back through the archives but nothing specific came up. I am not a Java programmer, and I only came across rxtx a few days ago. I use a piece of test equipment called a miniVNA http://www.miniradiosolutions.com/ This is a serial USB controlled instrument, and it has control software available for MS windows, and a very old and now non-working Linux application. A few days ago Dietmar, DL2SBA released a Java application to control the miniVNA, obviously this application makes use of rxtx. The program worked fine on Windows, so I set about installing it onto Linux. I use SUSE11.1 After a few false starts, I got the system running fairly easily, sorting out the file locking by adding the uucp group to the users account as suggested (I used the 2.2pre binary files) I then passed the install instructions onto another miniVNA user, who also uses SUSE, but he ran into problems. To cut a long story short, he was also having file lock problems, but the uucp fix did not work. Digging into his system I found that there have been some changes in SUSE 11.2. tty ports are now assigned to the dialout group rather than uucp. A hint in the rxtx INSTALL file, suggested that var/lock needs to be checked, so: SUSE 11.1, var/lock is root:uucp SUSE 11.2 var/lock is root:root A search on Google brought up several comments regarding this, and also a bugzilla entry. https://bugzilla.novell.com/show_bug.cgi?id=552095 However from reading the various posts, some of which are in the bugzilla entry, it appears that many distros may be, or have changed to this configuration, and this will undoubtedly break several things, rxtx included. I solved my fellow SUSE users problem by compiling the rxtx libs with the no lock file option during configure, and that solved his problem. As this issue will probably take some time to get resolved across all the various Linux distros, it might be worth considering changing the default on the Linux build of rxtx not to use lockfiles, or provide the two versions of the lib in the binary archive. Thanks for your indulgence Andy From damorales at gmail.com Wed Feb 3 11:33:23 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 15:33:23 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203180904.164f24dd@workstation.site> References: <20100203180904.164f24dd@workstation.site> Message-ID: Hi I had the same problem in Mandriva 2010 and yes, adding the user to the uucp group did not work as it used to be in earlier versions of linux distros, causing RXTX to not work as non root user. The problem appears because the existense of UDEV, now you MUST add a RULE so the group (uucp or whatever) have access (Read, Write, Execute) to the Serial Port. To solve the problem, without needing to recompile RXTX, you must add a rule to grant permissions (0666) to the group for the device or port (tty*, ttyUSB*, etc). I do not remember now what is the line i added but when i come back home i will give it to you (i am at work now). Greetings ! 2010/2/3 > Hello RXTX group, > > I have just joined this group, and this is my first posting. > I wanted to pass on some information regarding rxtx, so apologies if > this has been brought up before. I have searched back through the > archives but nothing specific came up. > > I am not a Java programmer, and I only came across rxtx a few days ago. > > I use a piece of test equipment called a miniVNA > http://www.miniradiosolutions.com/ > > This is a serial USB controlled instrument, and it has control software > available for MS windows, and a very old and now non-working Linux > application. > > A few days ago Dietmar, DL2SBA released a Java application to control the > miniVNA, obviously this application makes use of rxtx. > > The program worked fine on Windows, so I set about installing it onto > Linux. I use SUSE11.1 After a few false starts, I got the system running > fairly easily, sorting out the file locking by adding the uucp group to > the users account as suggested (I used the 2.2pre binary files) I then > passed the install instructions onto another miniVNA user, who also uses > SUSE, but he ran into problems. To cut a long story short, he was > also having file lock problems, but the uucp fix did not work. Digging > into his system I found that there have been some changes in SUSE 11.2. > > tty ports are now assigned to the dialout group rather than uucp. > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > checked, so: > > SUSE 11.1, var/lock is root:uucp > SUSE 11.2 var/lock is root:root > > A search on Google brought up several comments regarding this, and also > a bugzilla entry. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > However from reading the various posts, some of which are in the bugzilla > entry, it appears that many distros may be, or have changed to this > configuration, and this will undoubtedly break several things, rxtx > included. > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > no lock file option during configure, and that solved his problem. > > As this issue will probably take some time to get resolved across all the > various Linux distros, it might be worth considering changing the default > on the Linux build of rxtx not to use lockfiles, or provide the two > versions of the lib in the binary archive. > > Thanks for your indulgence > > Andy > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Wed Feb 3 12:07:02 2010 From: andy at g0poy.com (Andy Eskelson) Date: Wed, 3 Feb 2010 19:07:02 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> Message-ID: <20100203190702.1b0e7015@workstation.site> Thanks Daniel, I am aware of the permissions problem, I have had a udev rules to solve this for other programs for some time. . I don't think that this is the same problem. as far as I can understand things, the lock files are written in var/lock. Previously var/lock and dev/tty-whatever were the same group. Now with var/lock owned by and with a group of root:root anything other than root cannot create a lock file. Even minicom is broken by this change. This change is going to have quite a few knock-on effects I think. Andy On Wed, 3 Feb 2010 15:33:23 -0300 Daniel Morales Salas wrote: > Hi > > I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > group did not work as it used to be in earlier versions of linux distros, > causing RXTX to not work as non root user. > > The problem appears because the existense of UDEV, now you MUST add a RULE > so the group (uucp or whatever) have access (Read, Write, Execute) to the > Serial Port. > > To solve the problem, without needing to recompile RXTX, you must add a rule > to grant permissions (0666) to the group for the device or port (tty*, > ttyUSB*, etc). I do not remember now what is the line i added but when i > come back home i will give it to you (i am at work now). > > Greetings ! > > 2010/2/3 > > > Hello RXTX group, > > > > I have just joined this group, and this is my first posting. > > I wanted to pass on some information regarding rxtx, so apologies if > > this has been brought up before. I have searched back through the > > archives but nothing specific came up. > > > > I am not a Java programmer, and I only came across rxtx a few days ago. > > > > I use a piece of test equipment called a miniVNA > > http://www.miniradiosolutions.com/ > > > > This is a serial USB controlled instrument, and it has control software > > available for MS windows, and a very old and now non-working Linux > > application. > > > > A few days ago Dietmar, DL2SBA released a Java application to control the > > miniVNA, obviously this application makes use of rxtx. > > > > The program worked fine on Windows, so I set about installing it onto > > Linux. I use SUSE11.1 After a few false starts, I got the system running > > fairly easily, sorting out the file locking by adding the uucp group to > > the users account as suggested (I used the 2.2pre binary files) I then > > passed the install instructions onto another miniVNA user, who also uses > > SUSE, but he ran into problems. To cut a long story short, he was > > also having file lock problems, but the uucp fix did not work. Digging > > into his system I found that there have been some changes in SUSE 11.2. > > > > tty ports are now assigned to the dialout group rather than uucp. > > > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > checked, so: > > > > SUSE 11.1, var/lock is root:uucp > > SUSE 11.2 var/lock is root:root > > > > A search on Google brought up several comments regarding this, and also > > a bugzilla entry. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > However from reading the various posts, some of which are in the bugzilla > > entry, it appears that many distros may be, or have changed to this > > configuration, and this will undoubtedly break several things, rxtx > > included. > > > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > > no lock file option during configure, and that solved his problem. > > > > As this issue will probably take some time to get resolved across all the > > various Linux distros, it might be worth considering changing the default > > on the Linux build of rxtx not to use lockfiles, or provide the two > > versions of the lib in the binary archive. > > > > Thanks for your indulgence > > > > Andy > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From thisdyingdream at gmail.com Wed Feb 3 12:32:35 2010 From: thisdyingdream at gmail.com (Steven Harms) Date: Wed, 3 Feb 2010 14:32:35 -0500 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203190702.1b0e7015@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: This is currently a bug in OpenSUSE that affects more than just rxtx, and is a result of unified udev rules. You can work around this by making udev change the group back to uucp until something more happens. https://bugzilla.novell.com/show_bug.cgi?id=552095 Thanks, Steve On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > Thanks Daniel, > > I am aware of the permissions problem, I have had a udev rules to solve > this for other programs for some time. > . > I don't think that this is the same problem. as far as I can understand > things, the lock files are written in var/lock. Previously var/lock and > dev/tty-whatever were the same group. Now with var/lock owned by and with > a group of root:root anything other than root cannot create a lock > file. Even minicom is broken by this change. > > This change is going to have quite a few knock-on effects I think. > > > Andy > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > Daniel Morales Salas wrote: > >> Hi >> >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp >> group did not work as it used to be in earlier versions of linux distros, >> causing RXTX to not work as non root user. >> >> The problem appears because the existense of UDEV, now you MUST add a RULE >> so the group (uucp or whatever) have access (Read, Write, Execute) to the >> Serial Port. >> >> To solve the problem, without needing to recompile RXTX, you must add a rule >> to grant permissions (0666) to the group for the device or port (tty*, >> ttyUSB*, etc). I do not remember now what is the line i added but when i >> come back home i will give it to you (i am at work now). >> >> Greetings ! >> >> 2010/2/3 >> >> > Hello RXTX group, >> > >> > I have just joined this group, and this is my first posting. >> > I wanted to pass on ?some information regarding rxtx, so apologies if >> > this has been brought up before. I have searched back through the >> > archives but nothing specific came up. >> > >> > I am not a Java programmer, and I only came across rxtx a few days ago. >> > >> > I use a piece of test equipment called a miniVNA >> > http://www.miniradiosolutions.com/ >> > >> > This is a serial USB controlled instrument, and it has control software >> > available for MS windows, and a very old and now non-working Linux >> > application. >> > >> > A few days ago Dietmar, DL2SBA released a Java application to control the >> > miniVNA, obviously this application makes use of rxtx. >> > >> > The program worked fine on Windows, so I set about installing it onto >> > Linux. I use SUSE11.1 After a few false starts, I got the system running >> > fairly easily, sorting out the file locking by adding the uucp group to >> > the users account as suggested (I used the 2.2pre binary files) I then >> > passed the install instructions onto another miniVNA user, who also uses >> > SUSE, but he ran into problems. To cut a long story short, he was >> > also having file lock problems, but the uucp fix did not work. Digging >> > into his system I found that there have been some changes in SUSE 11.2. >> > >> > tty ports are now assigned to the dialout group rather than uucp. >> > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be >> > checked, so: >> > >> > SUSE 11.1, var/lock is root:uucp >> > SUSE 11.2 var/lock is root:root >> > >> > A search on Google brought up several comments regarding this, and also >> > a ?bugzilla entry. >> > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 >> > >> > However from reading the various posts, some of which are in the bugzilla >> > entry, it appears that many distros may be, or have changed to this >> > configuration, and this will undoubtedly break several things, rxtx >> > included. >> > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the >> > no lock file option during configure, and that solved his problem. >> > >> > As this issue will probably take some time to get resolved across all the >> > various Linux distros, it might be worth considering changing the default >> > on the Linux build of rxtx not to use lockfiles, or provide the two >> > versions of the lib in the binary archive. >> > >> > Thanks for your indulgence >> > >> > Andy >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> >> >> >> -- >> Atte: >> Daniel Dario Morales Salas >> Ingeniero Civil en Computaci?n e Inform?tica >> Tel?fono: 02 684 3417 >> Celular: 09 643 1802 >> Santiago, Chile > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 WWW: http://www.sharms.org/blog From andy at g0poy.com Wed Feb 3 17:58:29 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 00:58:29 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: <20100204005829.7dc944e1@workstation.site> Thanks Steve, changing the serial ports back the uucp is not a big problem. I have a udev rule that can be easily modified already. However I cannot see any way of dealing with the var/lock problem apart from making it writable to all. Any thoughts? Andy On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms wrote: > This is currently a bug in OpenSUSE that affects more than just rxtx, > and is a result of unified udev rules. You can work around this by > making udev change the group back to uucp until something more > happens. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > Thanks, > > Steve > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > Thanks Daniel, > > > > I am aware of the permissions problem, I have had a udev rules to solve > > this for other programs for some time. > > . > > I don't think that this is the same problem. as far as I can understand > > things, the lock files are written in var/lock. Previously var/lock and > > dev/tty-whatever were the same group. Now with var/lock owned by and with > > a group of root:root anything other than root cannot create a lock > > file. Even minicom is broken by this change. > > > > This change is going to have quite a few knock-on effects I think. > > > > > > Andy > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > Daniel Morales Salas wrote: > > > >> Hi > >> > >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > >> group did not work as it used to be in earlier versions of linux distros, > >> causing RXTX to not work as non root user. > >> > >> The problem appears because the existense of UDEV, now you MUST add a RULE > >> so the group (uucp or whatever) have access (Read, Write, Execute) to the > >> Serial Port. > >> > >> To solve the problem, without needing to recompile RXTX, you must add a rule > >> to grant permissions (0666) to the group for the device or port (tty*, > >> ttyUSB*, etc). I do not remember now what is the line i added but when i > >> come back home i will give it to you (i am at work now). > >> > >> Greetings ! > >> > >> 2010/2/3 > >> > >> > Hello RXTX group, > >> > > >> > I have just joined this group, and this is my first posting. > >> > I wanted to pass on ?some information regarding rxtx, so apologies if > >> > this has been brought up before. I have searched back through the > >> > archives but nothing specific came up. > >> > > >> > I am not a Java programmer, and I only came across rxtx a few days ago. > >> > > >> > I use a piece of test equipment called a miniVNA > >> > http://www.miniradiosolutions.com/ > >> > > >> > This is a serial USB controlled instrument, and it has control software > >> > available for MS windows, and a very old and now non-working Linux > >> > application. > >> > > >> > A few days ago Dietmar, DL2SBA released a Java application to control the > >> > miniVNA, obviously this application makes use of rxtx. > >> > > >> > The program worked fine on Windows, so I set about installing it onto > >> > Linux. I use SUSE11.1 After a few false starts, I got the system running > >> > fairly easily, sorting out the file locking by adding the uucp group to > >> > the users account as suggested (I used the 2.2pre binary files) I then > >> > passed the install instructions onto another miniVNA user, who also uses > >> > SUSE, but he ran into problems. To cut a long story short, he was > >> > also having file lock problems, but the uucp fix did not work. Digging > >> > into his system I found that there have been some changes in SUSE 11.2. > >> > > >> > tty ports are now assigned to the dialout group rather than uucp. > >> > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > >> > checked, so: > >> > > >> > SUSE 11.1, var/lock is root:uucp > >> > SUSE 11.2 var/lock is root:root > >> > > >> > A search on Google brought up several comments regarding this, and also > >> > a ?bugzilla entry. > >> > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > >> > > >> > However from reading the various posts, some of which are in the bugzilla > >> > entry, it appears that many distros may be, or have changed to this > >> > configuration, and this will undoubtedly break several things, rxtx > >> > included. > >> > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the > >> > no lock file option during configure, and that solved his problem. > >> > > >> > As this issue will probably take some time to get resolved across all the > >> > various Linux distros, it might be worth considering changing the default > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > >> > versions of the lib in the binary archive. > >> > > >> > Thanks for your indulgence > >> > > >> > Andy > >> > > >> > _______________________________________________ > >> > Rxtx mailing list > >> > Rxtx at qbang.org > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > >> > >> > >> > >> -- > >> Atte: > >> Daniel Dario Morales Salas > >> Ingeniero Civil en Computaci?n e Inform?tica > >> Tel?fono: 02 684 3417 > >> Celular: 09 643 1802 > >> Santiago, Chile > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > WWW: http://www.sharms.org/blog From damorales at gmail.com Wed Feb 3 18:26:38 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 22:26:38 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100204005829.7dc944e1@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: Hello I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva 2010 this is what i get: drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ and i don't have ANY problem with lock files and RXTX in my java software. All i had to do was add this rule to udev: # serial KERNEL=="tty*", GROUP="uucp", MODE="0666" and that was all. Of course my user (metalklesk) is part of uucp group. I did not make /var/lock writable to all users. Greetings ! 2010/2/3 Andy Eskelson > Thanks Steve, > > changing the serial ports back the uucp is not a big problem. I have a > udev rule that can be easily modified already. However I cannot see any > way of dealing with the var/lock problem apart from making it writable to > all. Any thoughts? > > Andy > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > wrote: > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > and is a result of unified udev rules. You can work around this by > > making udev change the group back to uucp until something more > > happens. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > Thanks, > > > > Steve > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > Thanks Daniel, > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > this for other programs for some time. > > > . > > > I don't think that this is the same problem. as far as I can understand > > > things, the lock files are written in var/lock. Previously var/lock and > > > dev/tty-whatever were the same group. Now with var/lock owned by and > with > > > a group of root:root anything other than root cannot create a lock > > > file. Even minicom is broken by this change. > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > Daniel Morales Salas wrote: > > > > > >> Hi > > >> > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > the uucp > > >> group did not work as it used to be in earlier versions of linux > distros, > > >> causing RXTX to not work as non root user. > > >> > > >> The problem appears because the existense of UDEV, now you MUST add a > RULE > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > the > > >> Serial Port. > > >> > > >> To solve the problem, without needing to recompile RXTX, you must add > a rule > > >> to grant permissions (0666) to the group for the device or port (tty*, > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > i > > >> come back home i will give it to you (i am at work now). > > >> > > >> Greetings ! > > >> > > >> 2010/2/3 > > >> > > >> > Hello RXTX group, > > >> > > > >> > I have just joined this group, and this is my first posting. > > >> > I wanted to pass on some information regarding rxtx, so apologies > if > > >> > this has been brought up before. I have searched back through the > > >> > archives but nothing specific came up. > > >> > > > >> > I am not a Java programmer, and I only came across rxtx a few days > ago. > > >> > > > >> > I use a piece of test equipment called a miniVNA > > >> > http://www.miniradiosolutions.com/ > > >> > > > >> > This is a serial USB controlled instrument, and it has control > software > > >> > available for MS windows, and a very old and now non-working Linux > > >> > application. > > >> > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > control the > > >> > miniVNA, obviously this application makes use of rxtx. > > >> > > > >> > The program worked fine on Windows, so I set about installing it > onto > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > running > > >> > fairly easily, sorting out the file locking by adding the uucp group > to > > >> > the users account as suggested (I used the 2.2pre binary files) I > then > > >> > passed the install instructions onto another miniVNA user, who also > uses > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > >> > also having file lock problems, but the uucp fix did not work. > Digging > > >> > into his system I found that there have been some changes in SUSE > 11.2. > > >> > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > >> > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > >> > checked, so: > > >> > > > >> > SUSE 11.1, var/lock is root:uucp > > >> > SUSE 11.2 var/lock is root:root > > >> > > > >> > A search on Google brought up several comments regarding this, and > also > > >> > a bugzilla entry. > > >> > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > >> > > > >> > However from reading the various posts, some of which are in the > bugzilla > > >> > entry, it appears that many distros may be, or have changed to this > > >> > configuration, and this will undoubtedly break several things, rxtx > > >> > included. > > >> > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > with the > > >> > no lock file option during configure, and that solved his problem. > > >> > > > >> > As this issue will probably take some time to get resolved across > all the > > >> > various Linux distros, it might be worth considering changing the > default > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > >> > versions of the lib in the binary archive. > > >> > > > >> > Thanks for your indulgence > > >> > > > >> > Andy > > >> > > > >> > _______________________________________________ > > >> > Rxtx mailing list > > >> > Rxtx at qbang.org > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > >> > > > >> > > >> > > >> > > >> -- > > >> Atte: > > >> Daniel Dario Morales Salas > > >> Ingeniero Civil en Computaci?n e Inform?tica > > >> Tel?fono: 02 684 3417 > > >> Celular: 09 643 1802 > > >> Santiago, Chile > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at qbang.org > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > -- > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > WWW: http://www.sharms.org/blog > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Thu Feb 4 05:31:46 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 12:31:46 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: <20100204123146.6cffeb67@workstation.site> Thank's for the confirmation. Something odd is going on somewhere in SUSE 11.2. I'll have to build up a local SUSE11.2 system to see if I can nail down exactly what is going on. Something is blocking the lockfiles in var/lock. The net is nice, but it's a bit difficult trying to work out what is going on what the machine in question is in Germany and I'm in the UK :-) Andy On Wed, 3 Feb 2010 22:26:38 -0300 Daniel Morales Salas wrote: > Hello > > I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva > 2010 this is what i get: > > drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ > > and i don't have ANY problem with lock files and RXTX in my java software. > All i had to do was add this rule to udev: > > # serial > KERNEL=="tty*", GROUP="uucp", MODE="0666" > > and that was all. Of course my user (metalklesk) is part of uucp group. > I did not make /var/lock writable to all users. > > Greetings ! > > 2010/2/3 Andy Eskelson > > > Thanks Steve, > > > > changing the serial ports back the uucp is not a big problem. I have a > > udev rule that can be easily modified already. However I cannot see any > > way of dealing with the var/lock problem apart from making it writable to > > all. Any thoughts? > > > > Andy > > > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > > wrote: > > > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > > and is a result of unified udev rules. You can work around this by > > > making udev change the group back to uucp until something more > > > happens. > > > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > > > Thanks, > > > > > > Steve > > > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > > Thanks Daniel, > > > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > > this for other programs for some time. > > > > . > > > > I don't think that this is the same problem. as far as I can understand > > > > things, the lock files are written in var/lock. Previously var/lock and > > > > dev/tty-whatever were the same group. Now with var/lock owned by and > > with > > > > a group of root:root anything other than root cannot create a lock > > > > file. Even minicom is broken by this change. > > > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > > Daniel Morales Salas wrote: > > > > > > > >> Hi > > > >> > > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > > the uucp > > > >> group did not work as it used to be in earlier versions of linux > > distros, > > > >> causing RXTX to not work as non root user. > > > >> > > > >> The problem appears because the existense of UDEV, now you MUST add a > > RULE > > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > > the > > > >> Serial Port. > > > >> > > > >> To solve the problem, without needing to recompile RXTX, you must add > > a rule > > > >> to grant permissions (0666) to the group for the device or port (tty*, > > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > > i > > > >> come back home i will give it to you (i am at work now). > > > >> > > > >> Greetings ! > > > >> > > > >> 2010/2/3 > > > >> > > > >> > Hello RXTX group, > > > >> > > > > >> > I have just joined this group, and this is my first posting. > > > >> > I wanted to pass on some information regarding rxtx, so apologies > > if > > > >> > this has been brought up before. I have searched back through the > > > >> > archives but nothing specific came up. > > > >> > > > > >> > I am not a Java programmer, and I only came across rxtx a few days > > ago. > > > >> > > > > >> > I use a piece of test equipment called a miniVNA > > > >> > http://www.miniradiosolutions.com/ > > > >> > > > > >> > This is a serial USB controlled instrument, and it has control > > software > > > >> > available for MS windows, and a very old and now non-working Linux > > > >> > application. > > > >> > > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > > control the > > > >> > miniVNA, obviously this application makes use of rxtx. > > > >> > > > > >> > The program worked fine on Windows, so I set about installing it > > onto > > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > > running > > > >> > fairly easily, sorting out the file locking by adding the uucp group > > to > > > >> > the users account as suggested (I used the 2.2pre binary files) I > > then > > > >> > passed the install instructions onto another miniVNA user, who also > > uses > > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > > >> > also having file lock problems, but the uucp fix did not work. > > Digging > > > >> > into his system I found that there have been some changes in SUSE > > 11.2. > > > >> > > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > > >> > > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > > >> > checked, so: > > > >> > > > > >> > SUSE 11.1, var/lock is root:uucp > > > >> > SUSE 11.2 var/lock is root:root > > > >> > > > > >> > A search on Google brought up several comments regarding this, and > > also > > > >> > a bugzilla entry. > > > >> > > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > >> > > > > >> > However from reading the various posts, some of which are in the > > bugzilla > > > >> > entry, it appears that many distros may be, or have changed to this > > > >> > configuration, and this will undoubtedly break several things, rxtx > > > >> > included. > > > >> > > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > > with the > > > >> > no lock file option during configure, and that solved his problem. > > > >> > > > > >> > As this issue will probably take some time to get resolved across > > all the > > > >> > various Linux distros, it might be worth considering changing the > > default > > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > > >> > versions of the lib in the binary archive. > > > >> > > > > >> > Thanks for your indulgence > > > >> > > > > >> > Andy > > > >> > > > > >> > _______________________________________________ > > > >> > Rxtx mailing list > > > >> > Rxtx at qbang.org > > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > > >> > > > > >> > > > >> > > > >> > > > >> -- > > > >> Atte: > > > >> Daniel Dario Morales Salas > > > >> Ingeniero Civil en Computaci?n e Inform?tica > > > >> Tel?fono: 02 684 3417 > > > >> Celular: 09 643 1802 > > > >> Santiago, Chile > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at qbang.org > > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > > > -- > > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > > > WWW: http://www.sharms.org/blog > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From Bob_Jacobsen at lbl.gov Thu Feb 4 09:26:49 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Thu, 4 Feb 2010 08:26:49 -0800 Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 Message-ID: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're using RXTX-2.2pre2, although it emits the known message about "Version mismatch". WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 After the usual messing around, we've got it working on 11 Windows versions, multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ have things working rarely say so, so I don't know whether anybody has gotten it to work on 10.4 or not. The problem encountered is this: dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib dyld: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib followed by the JVM crashing hard. I've got those dump files if that would help. Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If so, is there a patch I can get and build? Thanks Bob -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From tjarvi at qbang.org Thu Feb 4 14:22:21 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 4 Feb 2010 14:22:21 -0700 (MST) Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 In-Reply-To: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> References: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> Message-ID: On Thu, 4 Feb 2010, Bob Jacobsen wrote: > We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're > using RXTX-2.2pre2, although it emits the known message about "Version > mismatch". > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > > After the usual messing around, we've got it working on 11 Windows versions, > multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with > a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ > have things working rarely say so, so I don't know whether anybody has gotten > it to work on 10.4 or not. > > The problem encountered is this: > > dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > dyld: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > followed by the JVM crashing hard. I've got those dump files if that would > help. > > Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If > so, is there a patch I can get and build? > Hi Bob, I talked to a coworker about the problem you ran into. It appears that it is possible to target 'older' Mac systems through makefile configuration changes. "Configuring a Makefile-Based Project If you have a makefile-based project, you can also take advantage of SDK-based development, by adding the appropriate options to your compile and link commands. Using SDKs in makefile-based projects requires GCC 4.0 or later. To choose an SDK, you use the -isysroot option with the compiler and the -syslibroot option with the linker. Both options require that you specify the full path to the desired SDK directory. To set the Deployment OS version in a makefile, use a makefile variable of the form: ENVP= MACOSX_DEPLOYMENT_TARGET=10.4. To use this variable in your makefile, include it in front of your compile and link commands." http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html Or build on the oldest system you want to support. -- Trent Jarvi tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Thu Feb 4 14:56:19 2010 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Thu, 4 Feb 2010 14:56:19 -0700 Subject: [Rxtx] RXTX on 64 Bit Redhat In-Reply-To: References: <4ec9eab61001281448g3dd84910r867619948a4e0d7a@mail.gmail.com> Message-ID: Trent -- Finally fixed all my build related issues. I ran into another issue. On one of my machines my JDK is returning multiple folders for the "java.ext.dirs" (java.ext.dirs -> /opt/jdk1.6.0_17/jre/lib/ext:/usr/java/packages/lib/ext) system property. As a result my JVM wasn't able to detect the gnu.io.rxtx.properties. I am attaching a patch for RXTXCommDriver.java file to check for multiple locations. Also i have to assign permission 660 to all my dev ports to be located by RXTX. Pawan ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 5:12 PM To: Trent Jarvi Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Here is the error i get when i build the src from release-2-1-7 -bash-3.2$ make ( \ \ cd i686-pc-linux-gnu; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/ jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I/opt/jav a1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec - c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialImp.lo;\ if [ "Serial" = "Serial" ]; then \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I /opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_tim espec -c /home/jb_stg/rxtx/rxtx-devel/./src/fuserImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ else \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo; \ fi; \ ) gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/inclu de -I/opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need _timespec -c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -fPIC -DPIC -o /hom e/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/.libs/SerialImp.o /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:25:29: error: gnu_io_RXTXPort.h: No such file or directory In file included from /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:113: /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:91: error: expected specifier-qua lifier-list before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'jobject' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:408: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:409: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:410: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:411: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:415: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:416: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:417: error: expected '=', ',', '; ', 'asm' or '__attribute__' before 'is_interrupted' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:418: error: expected declaration specifiers or '...' before 'jint' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:424: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:441: error: expected ')' before ' *' token ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 4:57 PM To: Santosh Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Santosh -- Thank you. That fixed the issue. All -- What CVS branch or release should i use to get the latest RXTX src code. Pawan ________________________________ From: Santosh [mailto:santosh.ry at gmail.com] Sent: Thursday, January 28, 2010 3:49 PM To: Kharbanda, Pawan Cc: Trent Jarvi; rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat error "./configure: /bin/sh^M: bad interpreter: No such file or directory". I think you need to run dos2unix on script files before compiling. Thanks, Santosh On Thu, Jan 28, 2010 at 5:33 PM, Kharbanda, Pawan > wrote: Trent -- We are upgrading our exisiting OS and JDK on a project that rely heavily on RXTX api's. We are now using JDK1.6 32 bit (build 1.6.0_17-b04) and RedHat 5 on a 64 bit machine. Linux tocrhstg02.dot.state.co.us 2.6.18-164.6.1.el5 #1 SMP Tue Oct 27 11:30:06 EDT 2009 i686 i686 i386 GNU/Linux Red Hat Enterprise Linux Server release 5.4 (Tikanga) I tried to run version 2.1.7 r2 on it but not able to see any of my Digi ports I was able to access only /dev/ttyS0 (physical ports). Not sure if the problem is with the Digi driver or RXTX. I tried to open a Digi port with minicom and it worked fine. I also tried to get latest from CVS (rxtx-devel) and when I do "configure" I see this error "./configure: /bin/sh^M: bad interpreter: No such file or directory". Can someone please help me with this? Thanks for the help. Pawan _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch.txt URL: From juan.vicente.l.g at gmail.com Sat Feb 13 04:44:17 2010 From: juan.vicente.l.g at gmail.com (Juan Vicente Lopez Gutierrez) Date: Sat, 13 Feb 2010 12:44:17 +0100 Subject: [Rxtx] RXTX in macmini OSX 10.5 Message-ID: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> Hello. My name is Juanvi and I'm from Spain. I tried to launch a software created by me in the library CXR java to send information through the serial port and I can not make it work. In windows if I've done but not mac. I have a mac mini with OSX 10.5 and have read in the list of web mail that you CXR if you have managed to make it work on that operating system. I need you help me please. Do I make the mistake that shows me java: run: Stable Library =============================== Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 gnu.io.PortInUseException: Unknow Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:26) at TwoWatSerialComm.main(TwoWaySerialComm.java:106) Experimental: JNI_OnLoad called. GENERACION CORRECTA (total time: 0 seconds) I do not have permission to access the serial port, do not know. Os agradeceria much to sit down. A greeting and thanks. Pardon my English. Juanvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From juan.vicente.l.g at gmail.com Sat Feb 13 14:39:41 2010 From: juan.vicente.l.g at gmail.com (Juan Vicente Lopez Gutierrez) Date: Sat, 13 Feb 2010 22:39:41 +0100 Subject: [Rxtx] Fwd: RXTX in macmini OSX 10.5 In-Reply-To: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> References: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> Message-ID: <29405e5c1002131339m2059d169sdc8549ed9706a1af@mail.gmail.com> ---------- Forwarded message ---------- From: Juan Vicente Lopez Gutierrez Date: 2010/2/13 Subject: RXTX in macmini OSX 10.5 To: rxtx at qbang.org Hello. My name is Juanvi and I'm from Spain. I tried to launch a software created by me in the library CXR java to send information through the serial port and I can not make it work. In windows if I've done but not mac. I have a mac mini with OSX 10.5 and have read in the list of web mail that you CXR if you have managed to make it work on that operating system. I need you help me please. Do I make the mistake that shows me java: run: Stable Library =============================== Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 gnu.io.PortInUseException: Unknow Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:26) at TwoWatSerialComm.main(TwoWaySerialComm.java:106) Experimental: JNI_OnLoad called. GENERACION CORRECTA (total time: 0 seconds) I do not have permission to access the serial port, do not know. Os agradeceria much to sit down. A greeting and thanks. Pardon my English. Juanvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Mon Feb 22 04:35:48 2010 From: george.dma at gmail.com (George H) Date: Mon, 22 Feb 2010 13:35:48 +0200 Subject: [Rxtx] Lingering rxtx process Message-ID: Hi, I am using RXTX v2.1-7. I use it to communicate with 2 serial receipt printers and 1 serial line display device. My program runs well using the RXTX library on Windows and Linux. But... when I installed Linux on another hardware the program does not exit properly. By this I mean that the java program seems to have exited (passed the System.exit(0)) code but the console still does not return to the bash shell. I have to CTRL+C each time to kill the program. And on each restart RXTX has to remove stale LCK files. Just note I am only getting this on one machine, if it makes any difference it is an i686 system with all VIA chipsets and VIA-C7M NannoBGA2 processor. Any ideas? Thanks -- George H george.dma at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Mon Feb 22 04:43:43 2010 From: george.dma at gmail.com (George H) Date: Mon, 22 Feb 2010 13:43:43 +0200 Subject: [Rxtx] Lingering rxtx process Message-ID: Hi, I am using RXTX v2.1-7. I use it to communicate with 2 serial receipt printers and 1 serial line display device. My program runs well using the RXTX library on Windows and Linux. But... when I installed Linux on another hardware the program does not exit properly. By this I mean that the java program seems to have exited (passed the System.exit(0)) code but the console still does not return to the bash shell. I have to CTRL+C each time to kill the program. And on each restart RXTX has to remove stale LCK files. Just note I am only getting this on one machine, if it makes any difference it is an i686 system with all VIA chipsets and VIA-C7M NannoBGA2 processor. Any ideas? Thanks -- George H george.dma at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Tue Feb 23 01:29:42 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Tue, 23 Feb 2010 09:29:42 +0100 Subject: [Rxtx] Lingering rxtx process In-Reply-To: References: Message-ID: <73a89f361002230029w4a9ec14bt56d654e43c1c9623@mail.gmail.com> 2010/2/22 George H > Hi, > > I am using RXTX v2.1-7. > I use it to communicate with 2 serial receipt printers and 1 serial line > display device. My program runs well using the RXTX library on Windows and > Linux. > But... when I installed Linux on another hardware the program does not exit > properly. By this I mean that the java program seems to have exited (passed > the System.exit(0)) code but the console still does not return to the bash > shell. > > Thread in Noember 2009' - http://mailman.qbang.org/pipermail/rxtx/2009-November/5778408.html I have disocvered one technique which solved this problem in Linux Ubuntu and Mac for RXTX pre2.2, but should helps in 2.1.7 as well. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Thu Feb 25 02:41:46 2010 From: george.dma at gmail.com (George H) Date: Thu, 25 Feb 2010 11:41:46 +0200 Subject: [Rxtx] Lingering rxtx process In-Reply-To: <73a89f361002230029w4a9ec14bt56d654e43c1c9623@mail.gmail.com> References: <73a89f361002230029w4a9ec14bt56d654e43c1c9623@mail.gmail.com> Message-ID: With Mariusz Dec help and with the help of the threads that were mentioned http://mailman.qbang.org/pipermail/rxtx/2009-November/5790326.html http://embeddedfreak.wordpress.com/2008/10/08/rxtx-serial-port-helper/ I managed to solved my problem. I didn't really like it so much. I am not using the InputStream.read(byte[], int, int) method as for me I can break out of reading the stream if I get a '\n' or a 0x00. Either way the below code sample works for me. int data = 0; int len = 0; while(true) { data = commReader.getInputStream().read(); if(data == -1 || data == 0x00 || data == '\n' || commReader.getInputStream().available() < 1) { break; } if(len == buffer.length) { processData(buffer); clearBuffer(); } buffer[len++] = (byte)data; } Before I would loop the while until data != -1. But that blocks on .close() and my program never gets to exit. Adding .available() < 1 as a break condition fixes it when I call .close() I am going to see if this is a linux kernel configuration issue or not cos it isn't so obvious and I hardly ever use .available() when reading streams. Love the project though :) -- George H george.dma at gmail.com On Tue, Feb 23, 2010 at 10:29 AM, Mariusz Dec wrote: > > > 2010/2/22 George H > > Hi, >> >> I am using RXTX v2.1-7. >> I use it to communicate with 2 serial receipt printers and 1 serial line >> display device. My program runs well using the RXTX library on Windows and >> Linux. >> But... when I installed Linux on another hardware the program does not >> exit properly. By this I mean that the java program seems to have exited >> (passed the System.exit(0)) code but the console still does not return to >> the bash shell. >> >> Thread in Noember 2009' - > > http://mailman.qbang.org/pipermail/rxtx/2009-November/5778408.html > > I have disocvered one technique which solved this problem in Linux Ubuntu > and Mac for RXTX pre2.2, but should helps in 2.1.7 as well. > > Regards > Mariusz > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 01:02:21 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 13:32:21 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> My serial port driver(apparently) does not support receive timeout.I registered an event listener for DATA_AVAILABLE. However, the control never seems to come out of the 'while' loop.Shouldn't the InputStream.read return a '-1' immediately if no data is available (this seems to be the default operation)? This was tried on a x86 Linux desktop using rxtx-2.1-7 I've added the snippet for clarity: /******************************************************************************************************************************************************************************/ mySerialPort.enableReceiveThreshold(2000);//Trying to set a time limit for read calls System.out.println(mySerialPort.isReceiveTimeoutEnabled()); // I get FALSE, so its not supported on hardware. mySerialPort.addEventListener(this); mySerialPort.notifyOnDataAvailable(true);//register a event with //my SerialEvent listener implementation: public void serialEvent(SerialPortEvent arg0) { int newData=0; switch(arg0.getEventType()){ case SerialPortEvent.DATA_AVAILABLE: while (newData != -1) { try { newData = is.read();//This should eventually return a -1 if no data is available within a timeout.PROBLEM!! System.out.println("Got a byte from port:"+newData); if (newData == -1) { break; } } catch (IOException ex) { System.err.println(ex); return; } } break; } return; } /******************************************************************************************************************************************************************************/ Thanks and regards, Ravi From michael.erskine at ketech.com Wed Feb 3 02:26:50 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 09:26:50 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From michael.erskine at ketech.com Wed Feb 3 05:03:30 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 12:03:30 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > Michael Erskine > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > > Your event handler should handle the event and return immediately so that its > controlling thread can handle other events. I recommend a single read in the > following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) > reads all available bytes up to the size of the buffer returning the number of > bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } After posting this I considered the glaring possibility of the rawbuf read buffer being too small to receive all the available bytes and perhaps skipping data: after all, I'm guessing that is why we see so many posts asking for help with blocking implementations of read event handlers looping on "while(bytes are available)". I've spent this morning writing an extensive multi-threaded unit test suite that includes tests with a tiny buffer compared to the amount of data available and found that no data was being skipped. I now want to know why! The SerialPortEvent.DATA_AVAILABLE event must be being fired again if there is more data available on the input stream. If that is the case then it should be heavily documented with good examples in the wiki to avoid the types of developer anguish we see so regularly. BTW: I'm not at liberty to post the JUnit tests as they use my company's unit test suite framework. Regards, Michael Erskine. From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 06:18:04 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 18:48:04 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Hello Michael, I tried out your suggestion but the problem is that the read(rawbuf) blocks until the entire length of the rawbuf array has been read (blocking). I cannot decide on a reasonable size of the array because it varies from 2 bytes to as much as 50 byes (i'm communicating with a modem,each response is of a different length), which is why i wanted to use non blocking calls. But on a side note, read(byte[]) in turn calls the read() in a loop.In the native C function, the read is supposed to return a -1 upon timeout.But my driver does not support timeout.The default timeout value is zero and the linux select call upon zero time out causes an infinite wait.What am i missing...... Thanks and regards, Ravi Date: Wed, 3 Feb 2010 09:26:50 +0000 From: Michael Erskine To: "rxtx at qbang.org" Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: Content-Type: text/plain; charset="us-ascii" > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From m.kirkland at comcast.net Wed Feb 3 06:46:03 2010 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 3 Feb 2010 05:46:03 -0800 Subject: [Rxtx] One port blocking another port In-Reply-To: References: Message-ID: <68768633814F4D7D86761D34F0764FE0@bengal.net> It turns out this is caused by having the RTS/CTS flow control turned on and me not providing a true on the RTS pin. Somehow it seems the port timing out on a read allows the write to proceed. This is not an issue for my application but I wonder if the write should not proceed until the RTS pin is true even if a read times out. mk -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Monday, January 25, 2010 7:48 PM To: Mike Kirkland Cc: rxtx at qbang.org Subject: Re: [Rxtx] One port blocking another port On Mon, 25 Jan 2010, Mike Kirkland wrote: > > Hi All, > > ? > > I have a program that reads from one com port and writes to another com > port. It also does the same thing in reverse (reads from the second com port > and writes to the first one. It basically ties two com ports together. > > ? > > One port is very chatty and has a consent stream of data. The other port has > very little data. > > ? > > Both ports use a 5000 ms (5 second) time out. > > ? > > The issue I am having is that is appears that the first port?s write to the > second port is blocked while the second port is waiting for input. The first > port?s write proceeds only after the second port has timed out. > > ? > > I suppose I could have something twisted around in my code but I was > wondering if this is a know issue? > Hi Kirk, I've not seen a report like this. Perhaps some simple reproduction code will reveal a problem on your end or help us identify a problem in rxtx. I think there are several users doing multiport communication. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Wed Feb 3 07:03:58 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:03:58 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Message-ID: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> 2010/2/3 Ravishankar N > Hello Michael, > [..] > But on a side note, read(byte[]) in turn calls the read() in a loop.In the > native C function, the read is supposed to return a -1 upon timeout.But my > driver > does not support timeout.The default timeout value is zero and the linux > select call upon zero time out causes an infinite wait.What am i > missing...... > > When I have tested RXTX between platforms, I have observed "hangup" inside JNI driver when no data in Linux, is normal thing. Solution was setting the timeout for RXTX when no data from JNI driver. Something like that: commPort.enableReceiveTimeout(10); And it works perfect.... The only difference is that I am NOT using events - I am using continous read in separate thread and if data is available, is parsed and transferred to application using exception. Regards Mariusz > Thanks and regards, > Ravi > > Date: Wed, 3 Feb 2010 09:26:50 +0000 > From: Michael Erskine > To: "rxtx at qbang.org" > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > Message-ID: > > > Content-Type: text/plain; charset="us-ascii" > > > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of > > Ravishankar N > > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > > > My serial port driver(apparently) does not support receive timeout.I > > registered an event listener for DATA_AVAILABLE. However, the control > never > > seems to come out of the 'while' loop.Shouldn't the > > InputStream.read return a '-1' immediately if no data is available (this > seems > > to be the default operation)? > > Your event handler should handle the event and return immediately so that > its controlling thread can handle other events. I recommend a single read in > the following manner: rawbuf is a byte[] of "reasonable" size and the > read(byte[]) reads all available bytes up to the size of the buffer > returning the number of bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } > > This style of reading has worked for me with RXTX on Linux and Windows XP > for a good few years now in railway industry communications systems. Any > timeouts (largely unnecessary in my applications) can be handled elsewhere, > usually at a higher layer. > > Regards, > Michael Erskine. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Feb 3 07:22:55 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 3 Feb 2010 09:22:55 -0500 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: I'm guessing that this is driver specific. I recently had to support a select()/poll() infrastructure for a linux serial DD, its certainly non trivial to support async IO, so I suspect the problem in this case has to do with missing poll infrastructure in the device driver. This also has to coupled with special open flags for the device (which is within the rxtx code) The key routines within a 2.6 kernel linux device driver are shown below (if you have access to it for your particular device) are indicated below (here is a snippet from my device driver c code that supports polling/select). User space code to test this shown below also, note that the device needs to be opened with the O_NONBLOCK option to support the select/poll api // device driver code ..... /* * File operations supported by this driver. */ static struct file_operations iop_fops = { .owner = THIS_MODULE, .check_flags= iop_check_flags, .ioctl = iop_ioctl, .open = iop_open, .poll = iop_poll, // SUPPORT FOR SELECT/POLL infrastructure .read = iop_read, .release = iop_release, .write = iop_write, }; /** * Select/poll/epoll infrastructure. * * @param file * @param wait * * @return */ static unsigned int iop_poll(struct file *filp, poll_table *wait) { struct iop_device *devp = (struct iop_device *)filp->private_data; // the poll_table wait arg is an opaque pointer poll_wait(filp, &devp->readq, wait); // return from poll indicating whether we have read/write data unsigned int mask = 0; if (kfifo_len(devp->rx_fifo)) { mask |= (POLLIN | POLLRDNORM); } // @JC We don't do select on write yet // if (kfifo_len(devp->tx_fifo)) { // mask |= (POLLOUT | POLLWRNORM); // } // Only print out while debugging // if (mask != 0) { // printk (KERN_INFO "%s: [%04x]\n", __FUNCTION__, mask); // } return mask; } /** * device driver blocking and non blocking read function. This * function reads the requested number of bytes from the read * kfifo blocking as required. * * @param filp * @param buf * @param count * @param f_pos * * @return */ static ssize_t iop_read(struct file *filp, char __user *buf, size_t count, loff_t * ppos) { // access appropriate device struct struct iop_device *devp = (struct iop_device *) filp->private_data; ssize_t retval; // support non blocking mode (default) by checking if the kfifo is empty first if ((kfifo_len(devp->rx_fifo)==0) && (filp->f_flags & O_NONBLOCK)) { return -EAGAIN; } // wait for rx_fifo to receive data via receive interrupts retval = wait_event_interruptible(devp->readq, kfifo_len(devp->rx_fifo) != 0); // check for some error condition if (retval) { printk (KERN_ERR "%s: wait_event_interruptible returned[%d]\n", __FUNCTION__, retval); return retval; } // copy max requested bytes from rx_fifo to device buffer // this may still leave bytes in the kfifo for a subsequent read // if we are reading in a loop retval = kfifo_get(devp->rx_fifo, devp->rxbuf, count); // printk (KERN_INFO "%s: [%d] byte(s)\n", __FUNCTION__, retval); if (copy_to_user(buf, devp->rxbuf, retval)) { printk (KERN_ERR "%s: problem copying rx_fifo data to user buffer\n", __FUNCTION__); return -EFAULT; } return retval; } // a selection of my user space code reading via select()/poll()..... // user space open code iop_fd = ::open( deviceName.data(), O_RDWR | O_NONBLOCK); while ((bytes_to_expect - bytes_read) > 0) { // must reinitialize these between select calls fd_set readfds; FD_ZERO( &readfds ); FD_SET( iop_fd, &readfds ); // 1s sec read polling timeout struct timeval timeout; timeout.tv_sec = 1; timeout.tv_usec = 0; int rc = select( FD_SETSIZE, &readfds, NULL, NULL, &timeout ); // read from file when descriptor // indicates data available without blocking if ((rc > 0) && FD_ISSET(iop_fd, &readfds)) { // read into the appropriate offset within the rx_buf int temp = read(iop_fd, rx_buf + bytes_read, bytes_to_expect - bytes_read); if (!temp) { printf("EOF detected with %d bytes expected\n", bytes_to_expect - bytes_read); } else { bytes_read += temp; } } else if (rc < 0){ printf("%s: select on [%s], bytes_read[%d], errno=%d\n", __FUNCTION__, thread_args->device, bytes_read, errno); } else { printf("%s: select on [%s], bytes_read[%d], timeout\n", __FUNCTION__, thread_args->device, bytes_read); } } On Wed, Feb 3, 2010 at 9:03 AM, Mariusz Dec wrote: > > > 2010/2/3 Ravishankar N > >> Hello Michael, >> [..] >> >> But on a side note, read(byte[]) in turn calls the read() in a loop.In the >> native C function, the read is supposed to return a -1 upon timeout.But my >> driver >> does not support timeout.The default timeout value is zero and the linux >> select call upon zero time out causes an infinite wait.What am i >> missing...... >> >> > When I have tested RXTX between platforms, I have observed "hangup" inside > JNI driver when no data in Linux, is normal thing. > > Solution was setting the timeout for RXTX when no data from JNI driver. > > Something like that: > > commPort.enableReceiveTimeout(10); > > And it works perfect.... > > The only difference is that I am NOT using events - I am using continous > read in separate thread and if data is available, is parsed and transferred > to application using exception. > > Regards > Mariusz > > > >> Thanks and regards, >> Ravi >> >> Date: Wed, 3 Feb 2010 09:26:50 +0000 >> From: Michael Erskine >> To: "rxtx at qbang.org" >> Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? >> Message-ID: >> >> >> Content-Type: text/plain; charset="us-ascii" >> >> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >> Of >> > Ravishankar N >> > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? >> > >> > My serial port driver(apparently) does not support receive timeout.I >> > registered an event listener for DATA_AVAILABLE. However, the control >> never >> > seems to come out of the 'while' loop.Shouldn't the >> > InputStream.read return a '-1' immediately if no data is available (this >> seems >> > to be the default operation)? >> >> Your event handler should handle the event and return immediately so that >> its controlling thread can handle other events. I recommend a single read in >> the following manner: rawbuf is a byte[] of "reasonable" size and the >> read(byte[]) reads all available bytes up to the size of the buffer >> returning the number of bytes actually read... >> >> case SerialPortEvent.DATA_AVAILABLE: >> try { >> int i = is.read(rawbuf); >> if (i == -1) { >> << process EOF condition - should never happen >> >> return; >> } >> << process bytes (rawbuf, i); >> >> return; >> } catch (IOException e) { >> << promptly deal with exception >> >> return; >> } >> >> This style of reading has worked for me with RXTX on Linux and Windows XP >> for a good few years now in railway industry communications systems. Any >> timeouts (largely unnecessary in my applications) can be handled elsewhere, >> usually at a higher layer. >> >> Regards, >> Michael Erskine. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Feb 3 07:33:27 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:33:27 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: <73a89f361002030633j682610afia48dc7accd8e049b@mail.gmail.com> 2010/2/3 John Coffey > I'm guessing that this is driver specific. I recently had to support a > select()/poll() infrastructure for a linux serial DD, its certainly non > trivial to support async IO, so I suspect the problem in this case has to do > with missing poll infrastructure in the device driver. This also has to > coupled with special open flags for the device (which is within the rxtx > code) > > Yes, you are right, it may be driver specific, but in my case I haven't changed blocking JNI driver. I have added ONLY one call to RXTX method mentioned in my previous post and blocking (as seen as from Java app) gone out... Maybe this is not elegant, but works without problem in my app. I am using only FTDI chips and their drivers from couple of years and maybe this is the kind of the way to have no many problems with serial as well? Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From andyrxtx at g0poy.co.uk Wed Feb 3 11:09:04 2010 From: andyrxtx at g0poy.co.uk (andyrxtx at g0poy.co.uk) Date: Wed, 3 Feb 2010 18:09:04 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes Message-ID: <20100203180904.164f24dd@workstation.site> ?Hello RXTX group, I have just joined this group, and this is my first posting. I wanted to pass on some information regarding rxtx, so apologies if this has been brought up before. I have searched back through the archives but nothing specific came up. I am not a Java programmer, and I only came across rxtx a few days ago. I use a piece of test equipment called a miniVNA http://www.miniradiosolutions.com/ This is a serial USB controlled instrument, and it has control software available for MS windows, and a very old and now non-working Linux application. A few days ago Dietmar, DL2SBA released a Java application to control the miniVNA, obviously this application makes use of rxtx. The program worked fine on Windows, so I set about installing it onto Linux. I use SUSE11.1 After a few false starts, I got the system running fairly easily, sorting out the file locking by adding the uucp group to the users account as suggested (I used the 2.2pre binary files) I then passed the install instructions onto another miniVNA user, who also uses SUSE, but he ran into problems. To cut a long story short, he was also having file lock problems, but the uucp fix did not work. Digging into his system I found that there have been some changes in SUSE 11.2. tty ports are now assigned to the dialout group rather than uucp. A hint in the rxtx INSTALL file, suggested that var/lock needs to be checked, so: SUSE 11.1, var/lock is root:uucp SUSE 11.2 var/lock is root:root A search on Google brought up several comments regarding this, and also a bugzilla entry. https://bugzilla.novell.com/show_bug.cgi?id=552095 However from reading the various posts, some of which are in the bugzilla entry, it appears that many distros may be, or have changed to this configuration, and this will undoubtedly break several things, rxtx included. I solved my fellow SUSE users problem by compiling the rxtx libs with the no lock file option during configure, and that solved his problem. As this issue will probably take some time to get resolved across all the various Linux distros, it might be worth considering changing the default on the Linux build of rxtx not to use lockfiles, or provide the two versions of the lib in the binary archive. Thanks for your indulgence Andy From damorales at gmail.com Wed Feb 3 11:33:23 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 15:33:23 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203180904.164f24dd@workstation.site> References: <20100203180904.164f24dd@workstation.site> Message-ID: Hi I had the same problem in Mandriva 2010 and yes, adding the user to the uucp group did not work as it used to be in earlier versions of linux distros, causing RXTX to not work as non root user. The problem appears because the existense of UDEV, now you MUST add a RULE so the group (uucp or whatever) have access (Read, Write, Execute) to the Serial Port. To solve the problem, without needing to recompile RXTX, you must add a rule to grant permissions (0666) to the group for the device or port (tty*, ttyUSB*, etc). I do not remember now what is the line i added but when i come back home i will give it to you (i am at work now). Greetings ! 2010/2/3 > Hello RXTX group, > > I have just joined this group, and this is my first posting. > I wanted to pass on some information regarding rxtx, so apologies if > this has been brought up before. I have searched back through the > archives but nothing specific came up. > > I am not a Java programmer, and I only came across rxtx a few days ago. > > I use a piece of test equipment called a miniVNA > http://www.miniradiosolutions.com/ > > This is a serial USB controlled instrument, and it has control software > available for MS windows, and a very old and now non-working Linux > application. > > A few days ago Dietmar, DL2SBA released a Java application to control the > miniVNA, obviously this application makes use of rxtx. > > The program worked fine on Windows, so I set about installing it onto > Linux. I use SUSE11.1 After a few false starts, I got the system running > fairly easily, sorting out the file locking by adding the uucp group to > the users account as suggested (I used the 2.2pre binary files) I then > passed the install instructions onto another miniVNA user, who also uses > SUSE, but he ran into problems. To cut a long story short, he was > also having file lock problems, but the uucp fix did not work. Digging > into his system I found that there have been some changes in SUSE 11.2. > > tty ports are now assigned to the dialout group rather than uucp. > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > checked, so: > > SUSE 11.1, var/lock is root:uucp > SUSE 11.2 var/lock is root:root > > A search on Google brought up several comments regarding this, and also > a bugzilla entry. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > However from reading the various posts, some of which are in the bugzilla > entry, it appears that many distros may be, or have changed to this > configuration, and this will undoubtedly break several things, rxtx > included. > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > no lock file option during configure, and that solved his problem. > > As this issue will probably take some time to get resolved across all the > various Linux distros, it might be worth considering changing the default > on the Linux build of rxtx not to use lockfiles, or provide the two > versions of the lib in the binary archive. > > Thanks for your indulgence > > Andy > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Wed Feb 3 12:07:02 2010 From: andy at g0poy.com (Andy Eskelson) Date: Wed, 3 Feb 2010 19:07:02 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> Message-ID: <20100203190702.1b0e7015@workstation.site> Thanks Daniel, I am aware of the permissions problem, I have had a udev rules to solve this for other programs for some time. . I don't think that this is the same problem. as far as I can understand things, the lock files are written in var/lock. Previously var/lock and dev/tty-whatever were the same group. Now with var/lock owned by and with a group of root:root anything other than root cannot create a lock file. Even minicom is broken by this change. This change is going to have quite a few knock-on effects I think. Andy On Wed, 3 Feb 2010 15:33:23 -0300 Daniel Morales Salas wrote: > Hi > > I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > group did not work as it used to be in earlier versions of linux distros, > causing RXTX to not work as non root user. > > The problem appears because the existense of UDEV, now you MUST add a RULE > so the group (uucp or whatever) have access (Read, Write, Execute) to the > Serial Port. > > To solve the problem, without needing to recompile RXTX, you must add a rule > to grant permissions (0666) to the group for the device or port (tty*, > ttyUSB*, etc). I do not remember now what is the line i added but when i > come back home i will give it to you (i am at work now). > > Greetings ! > > 2010/2/3 > > > Hello RXTX group, > > > > I have just joined this group, and this is my first posting. > > I wanted to pass on some information regarding rxtx, so apologies if > > this has been brought up before. I have searched back through the > > archives but nothing specific came up. > > > > I am not a Java programmer, and I only came across rxtx a few days ago. > > > > I use a piece of test equipment called a miniVNA > > http://www.miniradiosolutions.com/ > > > > This is a serial USB controlled instrument, and it has control software > > available for MS windows, and a very old and now non-working Linux > > application. > > > > A few days ago Dietmar, DL2SBA released a Java application to control the > > miniVNA, obviously this application makes use of rxtx. > > > > The program worked fine on Windows, so I set about installing it onto > > Linux. I use SUSE11.1 After a few false starts, I got the system running > > fairly easily, sorting out the file locking by adding the uucp group to > > the users account as suggested (I used the 2.2pre binary files) I then > > passed the install instructions onto another miniVNA user, who also uses > > SUSE, but he ran into problems. To cut a long story short, he was > > also having file lock problems, but the uucp fix did not work. Digging > > into his system I found that there have been some changes in SUSE 11.2. > > > > tty ports are now assigned to the dialout group rather than uucp. > > > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > checked, so: > > > > SUSE 11.1, var/lock is root:uucp > > SUSE 11.2 var/lock is root:root > > > > A search on Google brought up several comments regarding this, and also > > a bugzilla entry. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > However from reading the various posts, some of which are in the bugzilla > > entry, it appears that many distros may be, or have changed to this > > configuration, and this will undoubtedly break several things, rxtx > > included. > > > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > > no lock file option during configure, and that solved his problem. > > > > As this issue will probably take some time to get resolved across all the > > various Linux distros, it might be worth considering changing the default > > on the Linux build of rxtx not to use lockfiles, or provide the two > > versions of the lib in the binary archive. > > > > Thanks for your indulgence > > > > Andy > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From thisdyingdream at gmail.com Wed Feb 3 12:32:35 2010 From: thisdyingdream at gmail.com (Steven Harms) Date: Wed, 3 Feb 2010 14:32:35 -0500 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203190702.1b0e7015@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: This is currently a bug in OpenSUSE that affects more than just rxtx, and is a result of unified udev rules. You can work around this by making udev change the group back to uucp until something more happens. https://bugzilla.novell.com/show_bug.cgi?id=552095 Thanks, Steve On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > Thanks Daniel, > > I am aware of the permissions problem, I have had a udev rules to solve > this for other programs for some time. > . > I don't think that this is the same problem. as far as I can understand > things, the lock files are written in var/lock. Previously var/lock and > dev/tty-whatever were the same group. Now with var/lock owned by and with > a group of root:root anything other than root cannot create a lock > file. Even minicom is broken by this change. > > This change is going to have quite a few knock-on effects I think. > > > Andy > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > Daniel Morales Salas wrote: > >> Hi >> >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp >> group did not work as it used to be in earlier versions of linux distros, >> causing RXTX to not work as non root user. >> >> The problem appears because the existense of UDEV, now you MUST add a RULE >> so the group (uucp or whatever) have access (Read, Write, Execute) to the >> Serial Port. >> >> To solve the problem, without needing to recompile RXTX, you must add a rule >> to grant permissions (0666) to the group for the device or port (tty*, >> ttyUSB*, etc). I do not remember now what is the line i added but when i >> come back home i will give it to you (i am at work now). >> >> Greetings ! >> >> 2010/2/3 >> >> > Hello RXTX group, >> > >> > I have just joined this group, and this is my first posting. >> > I wanted to pass on ?some information regarding rxtx, so apologies if >> > this has been brought up before. I have searched back through the >> > archives but nothing specific came up. >> > >> > I am not a Java programmer, and I only came across rxtx a few days ago. >> > >> > I use a piece of test equipment called a miniVNA >> > http://www.miniradiosolutions.com/ >> > >> > This is a serial USB controlled instrument, and it has control software >> > available for MS windows, and a very old and now non-working Linux >> > application. >> > >> > A few days ago Dietmar, DL2SBA released a Java application to control the >> > miniVNA, obviously this application makes use of rxtx. >> > >> > The program worked fine on Windows, so I set about installing it onto >> > Linux. I use SUSE11.1 After a few false starts, I got the system running >> > fairly easily, sorting out the file locking by adding the uucp group to >> > the users account as suggested (I used the 2.2pre binary files) I then >> > passed the install instructions onto another miniVNA user, who also uses >> > SUSE, but he ran into problems. To cut a long story short, he was >> > also having file lock problems, but the uucp fix did not work. Digging >> > into his system I found that there have been some changes in SUSE 11.2. >> > >> > tty ports are now assigned to the dialout group rather than uucp. >> > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be >> > checked, so: >> > >> > SUSE 11.1, var/lock is root:uucp >> > SUSE 11.2 var/lock is root:root >> > >> > A search on Google brought up several comments regarding this, and also >> > a ?bugzilla entry. >> > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 >> > >> > However from reading the various posts, some of which are in the bugzilla >> > entry, it appears that many distros may be, or have changed to this >> > configuration, and this will undoubtedly break several things, rxtx >> > included. >> > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the >> > no lock file option during configure, and that solved his problem. >> > >> > As this issue will probably take some time to get resolved across all the >> > various Linux distros, it might be worth considering changing the default >> > on the Linux build of rxtx not to use lockfiles, or provide the two >> > versions of the lib in the binary archive. >> > >> > Thanks for your indulgence >> > >> > Andy >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> >> >> >> -- >> Atte: >> Daniel Dario Morales Salas >> Ingeniero Civil en Computaci?n e Inform?tica >> Tel?fono: 02 684 3417 >> Celular: 09 643 1802 >> Santiago, Chile > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 WWW: http://www.sharms.org/blog From andy at g0poy.com Wed Feb 3 17:58:29 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 00:58:29 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: <20100204005829.7dc944e1@workstation.site> Thanks Steve, changing the serial ports back the uucp is not a big problem. I have a udev rule that can be easily modified already. However I cannot see any way of dealing with the var/lock problem apart from making it writable to all. Any thoughts? Andy On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms wrote: > This is currently a bug in OpenSUSE that affects more than just rxtx, > and is a result of unified udev rules. You can work around this by > making udev change the group back to uucp until something more > happens. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > Thanks, > > Steve > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > Thanks Daniel, > > > > I am aware of the permissions problem, I have had a udev rules to solve > > this for other programs for some time. > > . > > I don't think that this is the same problem. as far as I can understand > > things, the lock files are written in var/lock. Previously var/lock and > > dev/tty-whatever were the same group. Now with var/lock owned by and with > > a group of root:root anything other than root cannot create a lock > > file. Even minicom is broken by this change. > > > > This change is going to have quite a few knock-on effects I think. > > > > > > Andy > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > Daniel Morales Salas wrote: > > > >> Hi > >> > >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > >> group did not work as it used to be in earlier versions of linux distros, > >> causing RXTX to not work as non root user. > >> > >> The problem appears because the existense of UDEV, now you MUST add a RULE > >> so the group (uucp or whatever) have access (Read, Write, Execute) to the > >> Serial Port. > >> > >> To solve the problem, without needing to recompile RXTX, you must add a rule > >> to grant permissions (0666) to the group for the device or port (tty*, > >> ttyUSB*, etc). I do not remember now what is the line i added but when i > >> come back home i will give it to you (i am at work now). > >> > >> Greetings ! > >> > >> 2010/2/3 > >> > >> > Hello RXTX group, > >> > > >> > I have just joined this group, and this is my first posting. > >> > I wanted to pass on ?some information regarding rxtx, so apologies if > >> > this has been brought up before. I have searched back through the > >> > archives but nothing specific came up. > >> > > >> > I am not a Java programmer, and I only came across rxtx a few days ago. > >> > > >> > I use a piece of test equipment called a miniVNA > >> > http://www.miniradiosolutions.com/ > >> > > >> > This is a serial USB controlled instrument, and it has control software > >> > available for MS windows, and a very old and now non-working Linux > >> > application. > >> > > >> > A few days ago Dietmar, DL2SBA released a Java application to control the > >> > miniVNA, obviously this application makes use of rxtx. > >> > > >> > The program worked fine on Windows, so I set about installing it onto > >> > Linux. I use SUSE11.1 After a few false starts, I got the system running > >> > fairly easily, sorting out the file locking by adding the uucp group to > >> > the users account as suggested (I used the 2.2pre binary files) I then > >> > passed the install instructions onto another miniVNA user, who also uses > >> > SUSE, but he ran into problems. To cut a long story short, he was > >> > also having file lock problems, but the uucp fix did not work. Digging > >> > into his system I found that there have been some changes in SUSE 11.2. > >> > > >> > tty ports are now assigned to the dialout group rather than uucp. > >> > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > >> > checked, so: > >> > > >> > SUSE 11.1, var/lock is root:uucp > >> > SUSE 11.2 var/lock is root:root > >> > > >> > A search on Google brought up several comments regarding this, and also > >> > a ?bugzilla entry. > >> > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > >> > > >> > However from reading the various posts, some of which are in the bugzilla > >> > entry, it appears that many distros may be, or have changed to this > >> > configuration, and this will undoubtedly break several things, rxtx > >> > included. > >> > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the > >> > no lock file option during configure, and that solved his problem. > >> > > >> > As this issue will probably take some time to get resolved across all the > >> > various Linux distros, it might be worth considering changing the default > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > >> > versions of the lib in the binary archive. > >> > > >> > Thanks for your indulgence > >> > > >> > Andy > >> > > >> > _______________________________________________ > >> > Rxtx mailing list > >> > Rxtx at qbang.org > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > >> > >> > >> > >> -- > >> Atte: > >> Daniel Dario Morales Salas > >> Ingeniero Civil en Computaci?n e Inform?tica > >> Tel?fono: 02 684 3417 > >> Celular: 09 643 1802 > >> Santiago, Chile > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > WWW: http://www.sharms.org/blog From damorales at gmail.com Wed Feb 3 18:26:38 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 22:26:38 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100204005829.7dc944e1@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: Hello I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva 2010 this is what i get: drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ and i don't have ANY problem with lock files and RXTX in my java software. All i had to do was add this rule to udev: # serial KERNEL=="tty*", GROUP="uucp", MODE="0666" and that was all. Of course my user (metalklesk) is part of uucp group. I did not make /var/lock writable to all users. Greetings ! 2010/2/3 Andy Eskelson > Thanks Steve, > > changing the serial ports back the uucp is not a big problem. I have a > udev rule that can be easily modified already. However I cannot see any > way of dealing with the var/lock problem apart from making it writable to > all. Any thoughts? > > Andy > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > wrote: > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > and is a result of unified udev rules. You can work around this by > > making udev change the group back to uucp until something more > > happens. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > Thanks, > > > > Steve > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > Thanks Daniel, > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > this for other programs for some time. > > > . > > > I don't think that this is the same problem. as far as I can understand > > > things, the lock files are written in var/lock. Previously var/lock and > > > dev/tty-whatever were the same group. Now with var/lock owned by and > with > > > a group of root:root anything other than root cannot create a lock > > > file. Even minicom is broken by this change. > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > Daniel Morales Salas wrote: > > > > > >> Hi > > >> > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > the uucp > > >> group did not work as it used to be in earlier versions of linux > distros, > > >> causing RXTX to not work as non root user. > > >> > > >> The problem appears because the existense of UDEV, now you MUST add a > RULE > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > the > > >> Serial Port. > > >> > > >> To solve the problem, without needing to recompile RXTX, you must add > a rule > > >> to grant permissions (0666) to the group for the device or port (tty*, > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > i > > >> come back home i will give it to you (i am at work now). > > >> > > >> Greetings ! > > >> > > >> 2010/2/3 > > >> > > >> > Hello RXTX group, > > >> > > > >> > I have just joined this group, and this is my first posting. > > >> > I wanted to pass on some information regarding rxtx, so apologies > if > > >> > this has been brought up before. I have searched back through the > > >> > archives but nothing specific came up. > > >> > > > >> > I am not a Java programmer, and I only came across rxtx a few days > ago. > > >> > > > >> > I use a piece of test equipment called a miniVNA > > >> > http://www.miniradiosolutions.com/ > > >> > > > >> > This is a serial USB controlled instrument, and it has control > software > > >> > available for MS windows, and a very old and now non-working Linux > > >> > application. > > >> > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > control the > > >> > miniVNA, obviously this application makes use of rxtx. > > >> > > > >> > The program worked fine on Windows, so I set about installing it > onto > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > running > > >> > fairly easily, sorting out the file locking by adding the uucp group > to > > >> > the users account as suggested (I used the 2.2pre binary files) I > then > > >> > passed the install instructions onto another miniVNA user, who also > uses > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > >> > also having file lock problems, but the uucp fix did not work. > Digging > > >> > into his system I found that there have been some changes in SUSE > 11.2. > > >> > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > >> > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > >> > checked, so: > > >> > > > >> > SUSE 11.1, var/lock is root:uucp > > >> > SUSE 11.2 var/lock is root:root > > >> > > > >> > A search on Google brought up several comments regarding this, and > also > > >> > a bugzilla entry. > > >> > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > >> > > > >> > However from reading the various posts, some of which are in the > bugzilla > > >> > entry, it appears that many distros may be, or have changed to this > > >> > configuration, and this will undoubtedly break several things, rxtx > > >> > included. > > >> > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > with the > > >> > no lock file option during configure, and that solved his problem. > > >> > > > >> > As this issue will probably take some time to get resolved across > all the > > >> > various Linux distros, it might be worth considering changing the > default > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > >> > versions of the lib in the binary archive. > > >> > > > >> > Thanks for your indulgence > > >> > > > >> > Andy > > >> > > > >> > _______________________________________________ > > >> > Rxtx mailing list > > >> > Rxtx at qbang.org > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > >> > > > >> > > >> > > >> > > >> -- > > >> Atte: > > >> Daniel Dario Morales Salas > > >> Ingeniero Civil en Computaci?n e Inform?tica > > >> Tel?fono: 02 684 3417 > > >> Celular: 09 643 1802 > > >> Santiago, Chile > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at qbang.org > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > -- > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > WWW: http://www.sharms.org/blog > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Thu Feb 4 05:31:46 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 12:31:46 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: <20100204123146.6cffeb67@workstation.site> Thank's for the confirmation. Something odd is going on somewhere in SUSE 11.2. I'll have to build up a local SUSE11.2 system to see if I can nail down exactly what is going on. Something is blocking the lockfiles in var/lock. The net is nice, but it's a bit difficult trying to work out what is going on what the machine in question is in Germany and I'm in the UK :-) Andy On Wed, 3 Feb 2010 22:26:38 -0300 Daniel Morales Salas wrote: > Hello > > I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva > 2010 this is what i get: > > drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ > > and i don't have ANY problem with lock files and RXTX in my java software. > All i had to do was add this rule to udev: > > # serial > KERNEL=="tty*", GROUP="uucp", MODE="0666" > > and that was all. Of course my user (metalklesk) is part of uucp group. > I did not make /var/lock writable to all users. > > Greetings ! > > 2010/2/3 Andy Eskelson > > > Thanks Steve, > > > > changing the serial ports back the uucp is not a big problem. I have a > > udev rule that can be easily modified already. However I cannot see any > > way of dealing with the var/lock problem apart from making it writable to > > all. Any thoughts? > > > > Andy > > > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > > wrote: > > > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > > and is a result of unified udev rules. You can work around this by > > > making udev change the group back to uucp until something more > > > happens. > > > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > > > Thanks, > > > > > > Steve > > > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > > Thanks Daniel, > > > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > > this for other programs for some time. > > > > . > > > > I don't think that this is the same problem. as far as I can understand > > > > things, the lock files are written in var/lock. Previously var/lock and > > > > dev/tty-whatever were the same group. Now with var/lock owned by and > > with > > > > a group of root:root anything other than root cannot create a lock > > > > file. Even minicom is broken by this change. > > > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > > Daniel Morales Salas wrote: > > > > > > > >> Hi > > > >> > > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > > the uucp > > > >> group did not work as it used to be in earlier versions of linux > > distros, > > > >> causing RXTX to not work as non root user. > > > >> > > > >> The problem appears because the existense of UDEV, now you MUST add a > > RULE > > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > > the > > > >> Serial Port. > > > >> > > > >> To solve the problem, without needing to recompile RXTX, you must add > > a rule > > > >> to grant permissions (0666) to the group for the device or port (tty*, > > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > > i > > > >> come back home i will give it to you (i am at work now). > > > >> > > > >> Greetings ! > > > >> > > > >> 2010/2/3 > > > >> > > > >> > Hello RXTX group, > > > >> > > > > >> > I have just joined this group, and this is my first posting. > > > >> > I wanted to pass on some information regarding rxtx, so apologies > > if > > > >> > this has been brought up before. I have searched back through the > > > >> > archives but nothing specific came up. > > > >> > > > > >> > I am not a Java programmer, and I only came across rxtx a few days > > ago. > > > >> > > > > >> > I use a piece of test equipment called a miniVNA > > > >> > http://www.miniradiosolutions.com/ > > > >> > > > > >> > This is a serial USB controlled instrument, and it has control > > software > > > >> > available for MS windows, and a very old and now non-working Linux > > > >> > application. > > > >> > > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > > control the > > > >> > miniVNA, obviously this application makes use of rxtx. > > > >> > > > > >> > The program worked fine on Windows, so I set about installing it > > onto > > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > > running > > > >> > fairly easily, sorting out the file locking by adding the uucp group > > to > > > >> > the users account as suggested (I used the 2.2pre binary files) I > > then > > > >> > passed the install instructions onto another miniVNA user, who also > > uses > > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > > >> > also having file lock problems, but the uucp fix did not work. > > Digging > > > >> > into his system I found that there have been some changes in SUSE > > 11.2. > > > >> > > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > > >> > > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > > >> > checked, so: > > > >> > > > > >> > SUSE 11.1, var/lock is root:uucp > > > >> > SUSE 11.2 var/lock is root:root > > > >> > > > > >> > A search on Google brought up several comments regarding this, and > > also > > > >> > a bugzilla entry. > > > >> > > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > >> > > > > >> > However from reading the various posts, some of which are in the > > bugzilla > > > >> > entry, it appears that many distros may be, or have changed to this > > > >> > configuration, and this will undoubtedly break several things, rxtx > > > >> > included. > > > >> > > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > > with the > > > >> > no lock file option during configure, and that solved his problem. > > > >> > > > > >> > As this issue will probably take some time to get resolved across > > all the > > > >> > various Linux distros, it might be worth considering changing the > > default > > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > > >> > versions of the lib in the binary archive. > > > >> > > > > >> > Thanks for your indulgence > > > >> > > > > >> > Andy > > > >> > > > > >> > _______________________________________________ > > > >> > Rxtx mailing list > > > >> > Rxtx at qbang.org > > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > > >> > > > > >> > > > >> > > > >> > > > >> -- > > > >> Atte: > > > >> Daniel Dario Morales Salas > > > >> Ingeniero Civil en Computaci?n e Inform?tica > > > >> Tel?fono: 02 684 3417 > > > >> Celular: 09 643 1802 > > > >> Santiago, Chile > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at qbang.org > > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > > > -- > > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > > > WWW: http://www.sharms.org/blog > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From Bob_Jacobsen at lbl.gov Thu Feb 4 09:26:49 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Thu, 4 Feb 2010 08:26:49 -0800 Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 Message-ID: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're using RXTX-2.2pre2, although it emits the known message about "Version mismatch". WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 After the usual messing around, we've got it working on 11 Windows versions, multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ have things working rarely say so, so I don't know whether anybody has gotten it to work on 10.4 or not. The problem encountered is this: dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib dyld: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib followed by the JVM crashing hard. I've got those dump files if that would help. Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If so, is there a patch I can get and build? Thanks Bob -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From tjarvi at qbang.org Thu Feb 4 14:22:21 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 4 Feb 2010 14:22:21 -0700 (MST) Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 In-Reply-To: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> References: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> Message-ID: On Thu, 4 Feb 2010, Bob Jacobsen wrote: > We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're > using RXTX-2.2pre2, although it emits the known message about "Version > mismatch". > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > > After the usual messing around, we've got it working on 11 Windows versions, > multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with > a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ > have things working rarely say so, so I don't know whether anybody has gotten > it to work on 10.4 or not. > > The problem encountered is this: > > dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > dyld: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > followed by the JVM crashing hard. I've got those dump files if that would > help. > > Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If > so, is there a patch I can get and build? > Hi Bob, I talked to a coworker about the problem you ran into. It appears that it is possible to target 'older' Mac systems through makefile configuration changes. "Configuring a Makefile-Based Project If you have a makefile-based project, you can also take advantage of SDK-based development, by adding the appropriate options to your compile and link commands. Using SDKs in makefile-based projects requires GCC 4.0 or later. To choose an SDK, you use the -isysroot option with the compiler and the -syslibroot option with the linker. Both options require that you specify the full path to the desired SDK directory. To set the Deployment OS version in a makefile, use a makefile variable of the form: ENVP= MACOSX_DEPLOYMENT_TARGET=10.4. To use this variable in your makefile, include it in front of your compile and link commands." http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html Or build on the oldest system you want to support. -- Trent Jarvi tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Thu Feb 4 14:56:19 2010 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Thu, 4 Feb 2010 14:56:19 -0700 Subject: [Rxtx] RXTX on 64 Bit Redhat In-Reply-To: References: <4ec9eab61001281448g3dd84910r867619948a4e0d7a@mail.gmail.com> Message-ID: Trent -- Finally fixed all my build related issues. I ran into another issue. On one of my machines my JDK is returning multiple folders for the "java.ext.dirs" (java.ext.dirs -> /opt/jdk1.6.0_17/jre/lib/ext:/usr/java/packages/lib/ext) system property. As a result my JVM wasn't able to detect the gnu.io.rxtx.properties. I am attaching a patch for RXTXCommDriver.java file to check for multiple locations. Also i have to assign permission 660 to all my dev ports to be located by RXTX. Pawan ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 5:12 PM To: Trent Jarvi Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Here is the error i get when i build the src from release-2-1-7 -bash-3.2$ make ( \ \ cd i686-pc-linux-gnu; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/ jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I/opt/jav a1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec - c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialImp.lo;\ if [ "Serial" = "Serial" ]; then \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I /opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_tim espec -c /home/jb_stg/rxtx/rxtx-devel/./src/fuserImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ else \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo; \ fi; \ ) gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/inclu de -I/opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need _timespec -c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -fPIC -DPIC -o /hom e/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/.libs/SerialImp.o /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:25:29: error: gnu_io_RXTXPort.h: No such file or directory In file included from /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:113: /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:91: error: expected specifier-qua lifier-list before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'jobject' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:408: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:409: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:410: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:411: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:415: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:416: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:417: error: expected '=', ',', '; ', 'asm' or '__attribute__' before 'is_interrupted' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:418: error: expected declaration specifiers or '...' before 'jint' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:424: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:441: error: expected ')' before ' *' token ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 4:57 PM To: Santosh Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Santosh -- Thank you. That fixed the issue. All -- What CVS branch or release should i use to get the latest RXTX src code. Pawan ________________________________ From: Santosh [mailto:santosh.ry at gmail.com] Sent: Thursday, January 28, 2010 3:49 PM To: Kharbanda, Pawan Cc: Trent Jarvi; rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat error "./configure: /bin/sh^M: bad interpreter: No such file or directory". I think you need to run dos2unix on script files before compiling. Thanks, Santosh On Thu, Jan 28, 2010 at 5:33 PM, Kharbanda, Pawan > wrote: Trent -- We are upgrading our exisiting OS and JDK on a project that rely heavily on RXTX api's. We are now using JDK1.6 32 bit (build 1.6.0_17-b04) and RedHat 5 on a 64 bit machine. Linux tocrhstg02.dot.state.co.us 2.6.18-164.6.1.el5 #1 SMP Tue Oct 27 11:30:06 EDT 2009 i686 i686 i386 GNU/Linux Red Hat Enterprise Linux Server release 5.4 (Tikanga) I tried to run version 2.1.7 r2 on it but not able to see any of my Digi ports I was able to access only /dev/ttyS0 (physical ports). Not sure if the problem is with the Digi driver or RXTX. I tried to open a Digi port with minicom and it worked fine. I also tried to get latest from CVS (rxtx-devel) and when I do "configure" I see this error "./configure: /bin/sh^M: bad interpreter: No such file or directory". Can someone please help me with this? Thanks for the help. Pawan _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch.txt URL: From juan.vicente.l.g at gmail.com Sat Feb 13 04:44:17 2010 From: juan.vicente.l.g at gmail.com (Juan Vicente Lopez Gutierrez) Date: Sat, 13 Feb 2010 12:44:17 +0100 Subject: [Rxtx] RXTX in macmini OSX 10.5 Message-ID: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> Hello. My name is Juanvi and I'm from Spain. I tried to launch a software created by me in the library CXR java to send information through the serial port and I can not make it work. In windows if I've done but not mac. I have a mac mini with OSX 10.5 and have read in the list of web mail that you CXR if you have managed to make it work on that operating system. I need you help me please. Do I make the mistake that shows me java: run: Stable Library =============================== Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 gnu.io.PortInUseException: Unknow Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:26) at TwoWatSerialComm.main(TwoWaySerialComm.java:106) Experimental: JNI_OnLoad called. GENERACION CORRECTA (total time: 0 seconds) I do not have permission to access the serial port, do not know. Os agradeceria much to sit down. A greeting and thanks. Pardon my English. Juanvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From juan.vicente.l.g at gmail.com Sat Feb 13 14:39:41 2010 From: juan.vicente.l.g at gmail.com (Juan Vicente Lopez Gutierrez) Date: Sat, 13 Feb 2010 22:39:41 +0100 Subject: [Rxtx] Fwd: RXTX in macmini OSX 10.5 In-Reply-To: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> References: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> Message-ID: <29405e5c1002131339m2059d169sdc8549ed9706a1af@mail.gmail.com> ---------- Forwarded message ---------- From: Juan Vicente Lopez Gutierrez Date: 2010/2/13 Subject: RXTX in macmini OSX 10.5 To: rxtx at qbang.org Hello. My name is Juanvi and I'm from Spain. I tried to launch a software created by me in the library CXR java to send information through the serial port and I can not make it work. In windows if I've done but not mac. I have a mac mini with OSX 10.5 and have read in the list of web mail that you CXR if you have managed to make it work on that operating system. I need you help me please. Do I make the mistake that shows me java: run: Stable Library =============================== Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 gnu.io.PortInUseException: Unknow Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:26) at TwoWatSerialComm.main(TwoWaySerialComm.java:106) Experimental: JNI_OnLoad called. GENERACION CORRECTA (total time: 0 seconds) I do not have permission to access the serial port, do not know. Os agradeceria much to sit down. A greeting and thanks. Pardon my English. Juanvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Mon Feb 22 04:35:48 2010 From: george.dma at gmail.com (George H) Date: Mon, 22 Feb 2010 13:35:48 +0200 Subject: [Rxtx] Lingering rxtx process Message-ID: Hi, I am using RXTX v2.1-7. I use it to communicate with 2 serial receipt printers and 1 serial line display device. My program runs well using the RXTX library on Windows and Linux. But... when I installed Linux on another hardware the program does not exit properly. By this I mean that the java program seems to have exited (passed the System.exit(0)) code but the console still does not return to the bash shell. I have to CTRL+C each time to kill the program. And on each restart RXTX has to remove stale LCK files. Just note I am only getting this on one machine, if it makes any difference it is an i686 system with all VIA chipsets and VIA-C7M NannoBGA2 processor. Any ideas? Thanks -- George H george.dma at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Mon Feb 22 04:43:43 2010 From: george.dma at gmail.com (George H) Date: Mon, 22 Feb 2010 13:43:43 +0200 Subject: [Rxtx] Lingering rxtx process Message-ID: Hi, I am using RXTX v2.1-7. I use it to communicate with 2 serial receipt printers and 1 serial line display device. My program runs well using the RXTX library on Windows and Linux. But... when I installed Linux on another hardware the program does not exit properly. By this I mean that the java program seems to have exited (passed the System.exit(0)) code but the console still does not return to the bash shell. I have to CTRL+C each time to kill the program. And on each restart RXTX has to remove stale LCK files. Just note I am only getting this on one machine, if it makes any difference it is an i686 system with all VIA chipsets and VIA-C7M NannoBGA2 processor. Any ideas? Thanks -- George H george.dma at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Tue Feb 23 01:29:42 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Tue, 23 Feb 2010 09:29:42 +0100 Subject: [Rxtx] Lingering rxtx process In-Reply-To: References: Message-ID: <73a89f361002230029w4a9ec14bt56d654e43c1c9623@mail.gmail.com> 2010/2/22 George H > Hi, > > I am using RXTX v2.1-7. > I use it to communicate with 2 serial receipt printers and 1 serial line > display device. My program runs well using the RXTX library on Windows and > Linux. > But... when I installed Linux on another hardware the program does not exit > properly. By this I mean that the java program seems to have exited (passed > the System.exit(0)) code but the console still does not return to the bash > shell. > > Thread in Noember 2009' - http://mailman.qbang.org/pipermail/rxtx/2009-November/5778408.html I have disocvered one technique which solved this problem in Linux Ubuntu and Mac for RXTX pre2.2, but should helps in 2.1.7 as well. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Thu Feb 25 02:41:46 2010 From: george.dma at gmail.com (George H) Date: Thu, 25 Feb 2010 11:41:46 +0200 Subject: [Rxtx] Lingering rxtx process In-Reply-To: <73a89f361002230029w4a9ec14bt56d654e43c1c9623@mail.gmail.com> References: <73a89f361002230029w4a9ec14bt56d654e43c1c9623@mail.gmail.com> Message-ID: With Mariusz Dec help and with the help of the threads that were mentioned http://mailman.qbang.org/pipermail/rxtx/2009-November/5790326.html http://embeddedfreak.wordpress.com/2008/10/08/rxtx-serial-port-helper/ I managed to solved my problem. I didn't really like it so much. I am not using the InputStream.read(byte[], int, int) method as for me I can break out of reading the stream if I get a '\n' or a 0x00. Either way the below code sample works for me. int data = 0; int len = 0; while(true) { data = commReader.getInputStream().read(); if(data == -1 || data == 0x00 || data == '\n' || commReader.getInputStream().available() < 1) { break; } if(len == buffer.length) { processData(buffer); clearBuffer(); } buffer[len++] = (byte)data; } Before I would loop the while until data != -1. But that blocks on .close() and my program never gets to exit. Adding .available() < 1 as a break condition fixes it when I call .close() I am going to see if this is a linux kernel configuration issue or not cos it isn't so obvious and I hardly ever use .available() when reading streams. Love the project though :) -- George H george.dma at gmail.com On Tue, Feb 23, 2010 at 10:29 AM, Mariusz Dec wrote: > > > 2010/2/22 George H > > Hi, >> >> I am using RXTX v2.1-7. >> I use it to communicate with 2 serial receipt printers and 1 serial line >> display device. My program runs well using the RXTX library on Windows and >> Linux. >> But... when I installed Linux on another hardware the program does not >> exit properly. By this I mean that the java program seems to have exited >> (passed the System.exit(0)) code but the console still does not return to >> the bash shell. >> >> Thread in Noember 2009' - > > http://mailman.qbang.org/pipermail/rxtx/2009-November/5778408.html > > I have disocvered one technique which solved this problem in Linux Ubuntu > and Mac for RXTX pre2.2, but should helps in 2.1.7 as well. > > Regards > Mariusz > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 01:02:21 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 13:32:21 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> My serial port driver(apparently) does not support receive timeout.I registered an event listener for DATA_AVAILABLE. However, the control never seems to come out of the 'while' loop.Shouldn't the InputStream.read return a '-1' immediately if no data is available (this seems to be the default operation)? This was tried on a x86 Linux desktop using rxtx-2.1-7 I've added the snippet for clarity: /******************************************************************************************************************************************************************************/ mySerialPort.enableReceiveThreshold(2000);//Trying to set a time limit for read calls System.out.println(mySerialPort.isReceiveTimeoutEnabled()); // I get FALSE, so its not supported on hardware. mySerialPort.addEventListener(this); mySerialPort.notifyOnDataAvailable(true);//register a event with //my SerialEvent listener implementation: public void serialEvent(SerialPortEvent arg0) { int newData=0; switch(arg0.getEventType()){ case SerialPortEvent.DATA_AVAILABLE: while (newData != -1) { try { newData = is.read();//This should eventually return a -1 if no data is available within a timeout.PROBLEM!! System.out.println("Got a byte from port:"+newData); if (newData == -1) { break; } } catch (IOException ex) { System.err.println(ex); return; } } break; } return; } /******************************************************************************************************************************************************************************/ Thanks and regards, Ravi From michael.erskine at ketech.com Wed Feb 3 02:26:50 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 09:26:50 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From michael.erskine at ketech.com Wed Feb 3 05:03:30 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 12:03:30 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > Michael Erskine > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > > Your event handler should handle the event and return immediately so that its > controlling thread can handle other events. I recommend a single read in the > following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) > reads all available bytes up to the size of the buffer returning the number of > bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } After posting this I considered the glaring possibility of the rawbuf read buffer being too small to receive all the available bytes and perhaps skipping data: after all, I'm guessing that is why we see so many posts asking for help with blocking implementations of read event handlers looping on "while(bytes are available)". I've spent this morning writing an extensive multi-threaded unit test suite that includes tests with a tiny buffer compared to the amount of data available and found that no data was being skipped. I now want to know why! The SerialPortEvent.DATA_AVAILABLE event must be being fired again if there is more data available on the input stream. If that is the case then it should be heavily documented with good examples in the wiki to avoid the types of developer anguish we see so regularly. BTW: I'm not at liberty to post the JUnit tests as they use my company's unit test suite framework. Regards, Michael Erskine. From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 06:18:04 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 18:48:04 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Hello Michael, I tried out your suggestion but the problem is that the read(rawbuf) blocks until the entire length of the rawbuf array has been read (blocking). I cannot decide on a reasonable size of the array because it varies from 2 bytes to as much as 50 byes (i'm communicating with a modem,each response is of a different length), which is why i wanted to use non blocking calls. But on a side note, read(byte[]) in turn calls the read() in a loop.In the native C function, the read is supposed to return a -1 upon timeout.But my driver does not support timeout.The default timeout value is zero and the linux select call upon zero time out causes an infinite wait.What am i missing...... Thanks and regards, Ravi Date: Wed, 3 Feb 2010 09:26:50 +0000 From: Michael Erskine To: "rxtx at qbang.org" Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: Content-Type: text/plain; charset="us-ascii" > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From m.kirkland at comcast.net Wed Feb 3 06:46:03 2010 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 3 Feb 2010 05:46:03 -0800 Subject: [Rxtx] One port blocking another port In-Reply-To: References: Message-ID: <68768633814F4D7D86761D34F0764FE0@bengal.net> It turns out this is caused by having the RTS/CTS flow control turned on and me not providing a true on the RTS pin. Somehow it seems the port timing out on a read allows the write to proceed. This is not an issue for my application but I wonder if the write should not proceed until the RTS pin is true even if a read times out. mk -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Monday, January 25, 2010 7:48 PM To: Mike Kirkland Cc: rxtx at qbang.org Subject: Re: [Rxtx] One port blocking another port On Mon, 25 Jan 2010, Mike Kirkland wrote: > > Hi All, > > ? > > I have a program that reads from one com port and writes to another com > port. It also does the same thing in reverse (reads from the second com port > and writes to the first one. It basically ties two com ports together. > > ? > > One port is very chatty and has a consent stream of data. The other port has > very little data. > > ? > > Both ports use a 5000 ms (5 second) time out. > > ? > > The issue I am having is that is appears that the first port?s write to the > second port is blocked while the second port is waiting for input. The first > port?s write proceeds only after the second port has timed out. > > ? > > I suppose I could have something twisted around in my code but I was > wondering if this is a know issue? > Hi Kirk, I've not seen a report like this. Perhaps some simple reproduction code will reveal a problem on your end or help us identify a problem in rxtx. I think there are several users doing multiport communication. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Wed Feb 3 07:03:58 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:03:58 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Message-ID: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> 2010/2/3 Ravishankar N > Hello Michael, > [..] > But on a side note, read(byte[]) in turn calls the read() in a loop.In the > native C function, the read is supposed to return a -1 upon timeout.But my > driver > does not support timeout.The default timeout value is zero and the linux > select call upon zero time out causes an infinite wait.What am i > missing...... > > When I have tested RXTX between platforms, I have observed "hangup" inside JNI driver when no data in Linux, is normal thing. Solution was setting the timeout for RXTX when no data from JNI driver. Something like that: commPort.enableReceiveTimeout(10); And it works perfect.... The only difference is that I am NOT using events - I am using continous read in separate thread and if data is available, is parsed and transferred to application using exception. Regards Mariusz > Thanks and regards, > Ravi > > Date: Wed, 3 Feb 2010 09:26:50 +0000 > From: Michael Erskine > To: "rxtx at qbang.org" > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > Message-ID: > > > Content-Type: text/plain; charset="us-ascii" > > > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of > > Ravishankar N > > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > > > My serial port driver(apparently) does not support receive timeout.I > > registered an event listener for DATA_AVAILABLE. However, the control > never > > seems to come out of the 'while' loop.Shouldn't the > > InputStream.read return a '-1' immediately if no data is available (this > seems > > to be the default operation)? > > Your event handler should handle the event and return immediately so that > its controlling thread can handle other events. I recommend a single read in > the following manner: rawbuf is a byte[] of "reasonable" size and the > read(byte[]) reads all available bytes up to the size of the buffer > returning the number of bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } > > This style of reading has worked for me with RXTX on Linux and Windows XP > for a good few years now in railway industry communications systems. Any > timeouts (largely unnecessary in my applications) can be handled elsewhere, > usually at a higher layer. > > Regards, > Michael Erskine. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Feb 3 07:22:55 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 3 Feb 2010 09:22:55 -0500 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: I'm guessing that this is driver specific. I recently had to support a select()/poll() infrastructure for a linux serial DD, its certainly non trivial to support async IO, so I suspect the problem in this case has to do with missing poll infrastructure in the device driver. This also has to coupled with special open flags for the device (which is within the rxtx code) The key routines within a 2.6 kernel linux device driver are shown below (if you have access to it for your particular device) are indicated below (here is a snippet from my device driver c code that supports polling/select). User space code to test this shown below also, note that the device needs to be opened with the O_NONBLOCK option to support the select/poll api // device driver code ..... /* * File operations supported by this driver. */ static struct file_operations iop_fops = { .owner = THIS_MODULE, .check_flags= iop_check_flags, .ioctl = iop_ioctl, .open = iop_open, .poll = iop_poll, // SUPPORT FOR SELECT/POLL infrastructure .read = iop_read, .release = iop_release, .write = iop_write, }; /** * Select/poll/epoll infrastructure. * * @param file * @param wait * * @return */ static unsigned int iop_poll(struct file *filp, poll_table *wait) { struct iop_device *devp = (struct iop_device *)filp->private_data; // the poll_table wait arg is an opaque pointer poll_wait(filp, &devp->readq, wait); // return from poll indicating whether we have read/write data unsigned int mask = 0; if (kfifo_len(devp->rx_fifo)) { mask |= (POLLIN | POLLRDNORM); } // @JC We don't do select on write yet // if (kfifo_len(devp->tx_fifo)) { // mask |= (POLLOUT | POLLWRNORM); // } // Only print out while debugging // if (mask != 0) { // printk (KERN_INFO "%s: [%04x]\n", __FUNCTION__, mask); // } return mask; } /** * device driver blocking and non blocking read function. This * function reads the requested number of bytes from the read * kfifo blocking as required. * * @param filp * @param buf * @param count * @param f_pos * * @return */ static ssize_t iop_read(struct file *filp, char __user *buf, size_t count, loff_t * ppos) { // access appropriate device struct struct iop_device *devp = (struct iop_device *) filp->private_data; ssize_t retval; // support non blocking mode (default) by checking if the kfifo is empty first if ((kfifo_len(devp->rx_fifo)==0) && (filp->f_flags & O_NONBLOCK)) { return -EAGAIN; } // wait for rx_fifo to receive data via receive interrupts retval = wait_event_interruptible(devp->readq, kfifo_len(devp->rx_fifo) != 0); // check for some error condition if (retval) { printk (KERN_ERR "%s: wait_event_interruptible returned[%d]\n", __FUNCTION__, retval); return retval; } // copy max requested bytes from rx_fifo to device buffer // this may still leave bytes in the kfifo for a subsequent read // if we are reading in a loop retval = kfifo_get(devp->rx_fifo, devp->rxbuf, count); // printk (KERN_INFO "%s: [%d] byte(s)\n", __FUNCTION__, retval); if (copy_to_user(buf, devp->rxbuf, retval)) { printk (KERN_ERR "%s: problem copying rx_fifo data to user buffer\n", __FUNCTION__); return -EFAULT; } return retval; } // a selection of my user space code reading via select()/poll()..... // user space open code iop_fd = ::open( deviceName.data(), O_RDWR | O_NONBLOCK); while ((bytes_to_expect - bytes_read) > 0) { // must reinitialize these between select calls fd_set readfds; FD_ZERO( &readfds ); FD_SET( iop_fd, &readfds ); // 1s sec read polling timeout struct timeval timeout; timeout.tv_sec = 1; timeout.tv_usec = 0; int rc = select( FD_SETSIZE, &readfds, NULL, NULL, &timeout ); // read from file when descriptor // indicates data available without blocking if ((rc > 0) && FD_ISSET(iop_fd, &readfds)) { // read into the appropriate offset within the rx_buf int temp = read(iop_fd, rx_buf + bytes_read, bytes_to_expect - bytes_read); if (!temp) { printf("EOF detected with %d bytes expected\n", bytes_to_expect - bytes_read); } else { bytes_read += temp; } } else if (rc < 0){ printf("%s: select on [%s], bytes_read[%d], errno=%d\n", __FUNCTION__, thread_args->device, bytes_read, errno); } else { printf("%s: select on [%s], bytes_read[%d], timeout\n", __FUNCTION__, thread_args->device, bytes_read); } } On Wed, Feb 3, 2010 at 9:03 AM, Mariusz Dec wrote: > > > 2010/2/3 Ravishankar N > >> Hello Michael, >> [..] >> >> But on a side note, read(byte[]) in turn calls the read() in a loop.In the >> native C function, the read is supposed to return a -1 upon timeout.But my >> driver >> does not support timeout.The default timeout value is zero and the linux >> select call upon zero time out causes an infinite wait.What am i >> missing...... >> >> > When I have tested RXTX between platforms, I have observed "hangup" inside > JNI driver when no data in Linux, is normal thing. > > Solution was setting the timeout for RXTX when no data from JNI driver. > > Something like that: > > commPort.enableReceiveTimeout(10); > > And it works perfect.... > > The only difference is that I am NOT using events - I am using continous > read in separate thread and if data is available, is parsed and transferred > to application using exception. > > Regards > Mariusz > > > >> Thanks and regards, >> Ravi >> >> Date: Wed, 3 Feb 2010 09:26:50 +0000 >> From: Michael Erskine >> To: "rxtx at qbang.org" >> Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? >> Message-ID: >> >> >> Content-Type: text/plain; charset="us-ascii" >> >> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >> Of >> > Ravishankar N >> > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? >> > >> > My serial port driver(apparently) does not support receive timeout.I >> > registered an event listener for DATA_AVAILABLE. However, the control >> never >> > seems to come out of the 'while' loop.Shouldn't the >> > InputStream.read return a '-1' immediately if no data is available (this >> seems >> > to be the default operation)? >> >> Your event handler should handle the event and return immediately so that >> its controlling thread can handle other events. I recommend a single read in >> the following manner: rawbuf is a byte[] of "reasonable" size and the >> read(byte[]) reads all available bytes up to the size of the buffer >> returning the number of bytes actually read... >> >> case SerialPortEvent.DATA_AVAILABLE: >> try { >> int i = is.read(rawbuf); >> if (i == -1) { >> << process EOF condition - should never happen >> >> return; >> } >> << process bytes (rawbuf, i); >> >> return; >> } catch (IOException e) { >> << promptly deal with exception >> >> return; >> } >> >> This style of reading has worked for me with RXTX on Linux and Windows XP >> for a good few years now in railway industry communications systems. Any >> timeouts (largely unnecessary in my applications) can be handled elsewhere, >> usually at a higher layer. >> >> Regards, >> Michael Erskine. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Feb 3 07:33:27 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:33:27 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: <73a89f361002030633j682610afia48dc7accd8e049b@mail.gmail.com> 2010/2/3 John Coffey > I'm guessing that this is driver specific. I recently had to support a > select()/poll() infrastructure for a linux serial DD, its certainly non > trivial to support async IO, so I suspect the problem in this case has to do > with missing poll infrastructure in the device driver. This also has to > coupled with special open flags for the device (which is within the rxtx > code) > > Yes, you are right, it may be driver specific, but in my case I haven't changed blocking JNI driver. I have added ONLY one call to RXTX method mentioned in my previous post and blocking (as seen as from Java app) gone out... Maybe this is not elegant, but works without problem in my app. I am using only FTDI chips and their drivers from couple of years and maybe this is the kind of the way to have no many problems with serial as well? Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From andyrxtx at g0poy.co.uk Wed Feb 3 11:09:04 2010 From: andyrxtx at g0poy.co.uk (andyrxtx at g0poy.co.uk) Date: Wed, 3 Feb 2010 18:09:04 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes Message-ID: <20100203180904.164f24dd@workstation.site> ?Hello RXTX group, I have just joined this group, and this is my first posting. I wanted to pass on some information regarding rxtx, so apologies if this has been brought up before. I have searched back through the archives but nothing specific came up. I am not a Java programmer, and I only came across rxtx a few days ago. I use a piece of test equipment called a miniVNA http://www.miniradiosolutions.com/ This is a serial USB controlled instrument, and it has control software available for MS windows, and a very old and now non-working Linux application. A few days ago Dietmar, DL2SBA released a Java application to control the miniVNA, obviously this application makes use of rxtx. The program worked fine on Windows, so I set about installing it onto Linux. I use SUSE11.1 After a few false starts, I got the system running fairly easily, sorting out the file locking by adding the uucp group to the users account as suggested (I used the 2.2pre binary files) I then passed the install instructions onto another miniVNA user, who also uses SUSE, but he ran into problems. To cut a long story short, he was also having file lock problems, but the uucp fix did not work. Digging into his system I found that there have been some changes in SUSE 11.2. tty ports are now assigned to the dialout group rather than uucp. A hint in the rxtx INSTALL file, suggested that var/lock needs to be checked, so: SUSE 11.1, var/lock is root:uucp SUSE 11.2 var/lock is root:root A search on Google brought up several comments regarding this, and also a bugzilla entry. https://bugzilla.novell.com/show_bug.cgi?id=552095 However from reading the various posts, some of which are in the bugzilla entry, it appears that many distros may be, or have changed to this configuration, and this will undoubtedly break several things, rxtx included. I solved my fellow SUSE users problem by compiling the rxtx libs with the no lock file option during configure, and that solved his problem. As this issue will probably take some time to get resolved across all the various Linux distros, it might be worth considering changing the default on the Linux build of rxtx not to use lockfiles, or provide the two versions of the lib in the binary archive. Thanks for your indulgence Andy From damorales at gmail.com Wed Feb 3 11:33:23 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 15:33:23 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203180904.164f24dd@workstation.site> References: <20100203180904.164f24dd@workstation.site> Message-ID: Hi I had the same problem in Mandriva 2010 and yes, adding the user to the uucp group did not work as it used to be in earlier versions of linux distros, causing RXTX to not work as non root user. The problem appears because the existense of UDEV, now you MUST add a RULE so the group (uucp or whatever) have access (Read, Write, Execute) to the Serial Port. To solve the problem, without needing to recompile RXTX, you must add a rule to grant permissions (0666) to the group for the device or port (tty*, ttyUSB*, etc). I do not remember now what is the line i added but when i come back home i will give it to you (i am at work now). Greetings ! 2010/2/3 > Hello RXTX group, > > I have just joined this group, and this is my first posting. > I wanted to pass on some information regarding rxtx, so apologies if > this has been brought up before. I have searched back through the > archives but nothing specific came up. > > I am not a Java programmer, and I only came across rxtx a few days ago. > > I use a piece of test equipment called a miniVNA > http://www.miniradiosolutions.com/ > > This is a serial USB controlled instrument, and it has control software > available for MS windows, and a very old and now non-working Linux > application. > > A few days ago Dietmar, DL2SBA released a Java application to control the > miniVNA, obviously this application makes use of rxtx. > > The program worked fine on Windows, so I set about installing it onto > Linux. I use SUSE11.1 After a few false starts, I got the system running > fairly easily, sorting out the file locking by adding the uucp group to > the users account as suggested (I used the 2.2pre binary files) I then > passed the install instructions onto another miniVNA user, who also uses > SUSE, but he ran into problems. To cut a long story short, he was > also having file lock problems, but the uucp fix did not work. Digging > into his system I found that there have been some changes in SUSE 11.2. > > tty ports are now assigned to the dialout group rather than uucp. > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > checked, so: > > SUSE 11.1, var/lock is root:uucp > SUSE 11.2 var/lock is root:root > > A search on Google brought up several comments regarding this, and also > a bugzilla entry. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > However from reading the various posts, some of which are in the bugzilla > entry, it appears that many distros may be, or have changed to this > configuration, and this will undoubtedly break several things, rxtx > included. > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > no lock file option during configure, and that solved his problem. > > As this issue will probably take some time to get resolved across all the > various Linux distros, it might be worth considering changing the default > on the Linux build of rxtx not to use lockfiles, or provide the two > versions of the lib in the binary archive. > > Thanks for your indulgence > > Andy > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Wed Feb 3 12:07:02 2010 From: andy at g0poy.com (Andy Eskelson) Date: Wed, 3 Feb 2010 19:07:02 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> Message-ID: <20100203190702.1b0e7015@workstation.site> Thanks Daniel, I am aware of the permissions problem, I have had a udev rules to solve this for other programs for some time. . I don't think that this is the same problem. as far as I can understand things, the lock files are written in var/lock. Previously var/lock and dev/tty-whatever were the same group. Now with var/lock owned by and with a group of root:root anything other than root cannot create a lock file. Even minicom is broken by this change. This change is going to have quite a few knock-on effects I think. Andy On Wed, 3 Feb 2010 15:33:23 -0300 Daniel Morales Salas wrote: > Hi > > I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > group did not work as it used to be in earlier versions of linux distros, > causing RXTX to not work as non root user. > > The problem appears because the existense of UDEV, now you MUST add a RULE > so the group (uucp or whatever) have access (Read, Write, Execute) to the > Serial Port. > > To solve the problem, without needing to recompile RXTX, you must add a rule > to grant permissions (0666) to the group for the device or port (tty*, > ttyUSB*, etc). I do not remember now what is the line i added but when i > come back home i will give it to you (i am at work now). > > Greetings ! > > 2010/2/3 > > > Hello RXTX group, > > > > I have just joined this group, and this is my first posting. > > I wanted to pass on some information regarding rxtx, so apologies if > > this has been brought up before. I have searched back through the > > archives but nothing specific came up. > > > > I am not a Java programmer, and I only came across rxtx a few days ago. > > > > I use a piece of test equipment called a miniVNA > > http://www.miniradiosolutions.com/ > > > > This is a serial USB controlled instrument, and it has control software > > available for MS windows, and a very old and now non-working Linux > > application. > > > > A few days ago Dietmar, DL2SBA released a Java application to control the > > miniVNA, obviously this application makes use of rxtx. > > > > The program worked fine on Windows, so I set about installing it onto > > Linux. I use SUSE11.1 After a few false starts, I got the system running > > fairly easily, sorting out the file locking by adding the uucp group to > > the users account as suggested (I used the 2.2pre binary files) I then > > passed the install instructions onto another miniVNA user, who also uses > > SUSE, but he ran into problems. To cut a long story short, he was > > also having file lock problems, but the uucp fix did not work. Digging > > into his system I found that there have been some changes in SUSE 11.2. > > > > tty ports are now assigned to the dialout group rather than uucp. > > > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > checked, so: > > > > SUSE 11.1, var/lock is root:uucp > > SUSE 11.2 var/lock is root:root > > > > A search on Google brought up several comments regarding this, and also > > a bugzilla entry. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > However from reading the various posts, some of which are in the bugzilla > > entry, it appears that many distros may be, or have changed to this > > configuration, and this will undoubtedly break several things, rxtx > > included. > > > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > > no lock file option during configure, and that solved his problem. > > > > As this issue will probably take some time to get resolved across all the > > various Linux distros, it might be worth considering changing the default > > on the Linux build of rxtx not to use lockfiles, or provide the two > > versions of the lib in the binary archive. > > > > Thanks for your indulgence > > > > Andy > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From thisdyingdream at gmail.com Wed Feb 3 12:32:35 2010 From: thisdyingdream at gmail.com (Steven Harms) Date: Wed, 3 Feb 2010 14:32:35 -0500 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203190702.1b0e7015@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: This is currently a bug in OpenSUSE that affects more than just rxtx, and is a result of unified udev rules. You can work around this by making udev change the group back to uucp until something more happens. https://bugzilla.novell.com/show_bug.cgi?id=552095 Thanks, Steve On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > Thanks Daniel, > > I am aware of the permissions problem, I have had a udev rules to solve > this for other programs for some time. > . > I don't think that this is the same problem. as far as I can understand > things, the lock files are written in var/lock. Previously var/lock and > dev/tty-whatever were the same group. Now with var/lock owned by and with > a group of root:root anything other than root cannot create a lock > file. Even minicom is broken by this change. > > This change is going to have quite a few knock-on effects I think. > > > Andy > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > Daniel Morales Salas wrote: > >> Hi >> >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp >> group did not work as it used to be in earlier versions of linux distros, >> causing RXTX to not work as non root user. >> >> The problem appears because the existense of UDEV, now you MUST add a RULE >> so the group (uucp or whatever) have access (Read, Write, Execute) to the >> Serial Port. >> >> To solve the problem, without needing to recompile RXTX, you must add a rule >> to grant permissions (0666) to the group for the device or port (tty*, >> ttyUSB*, etc). I do not remember now what is the line i added but when i >> come back home i will give it to you (i am at work now). >> >> Greetings ! >> >> 2010/2/3 >> >> > Hello RXTX group, >> > >> > I have just joined this group, and this is my first posting. >> > I wanted to pass on ?some information regarding rxtx, so apologies if >> > this has been brought up before. I have searched back through the >> > archives but nothing specific came up. >> > >> > I am not a Java programmer, and I only came across rxtx a few days ago. >> > >> > I use a piece of test equipment called a miniVNA >> > http://www.miniradiosolutions.com/ >> > >> > This is a serial USB controlled instrument, and it has control software >> > available for MS windows, and a very old and now non-working Linux >> > application. >> > >> > A few days ago Dietmar, DL2SBA released a Java application to control the >> > miniVNA, obviously this application makes use of rxtx. >> > >> > The program worked fine on Windows, so I set about installing it onto >> > Linux. I use SUSE11.1 After a few false starts, I got the system running >> > fairly easily, sorting out the file locking by adding the uucp group to >> > the users account as suggested (I used the 2.2pre binary files) I then >> > passed the install instructions onto another miniVNA user, who also uses >> > SUSE, but he ran into problems. To cut a long story short, he was >> > also having file lock problems, but the uucp fix did not work. Digging >> > into his system I found that there have been some changes in SUSE 11.2. >> > >> > tty ports are now assigned to the dialout group rather than uucp. >> > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be >> > checked, so: >> > >> > SUSE 11.1, var/lock is root:uucp >> > SUSE 11.2 var/lock is root:root >> > >> > A search on Google brought up several comments regarding this, and also >> > a ?bugzilla entry. >> > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 >> > >> > However from reading the various posts, some of which are in the bugzilla >> > entry, it appears that many distros may be, or have changed to this >> > configuration, and this will undoubtedly break several things, rxtx >> > included. >> > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the >> > no lock file option during configure, and that solved his problem. >> > >> > As this issue will probably take some time to get resolved across all the >> > various Linux distros, it might be worth considering changing the default >> > on the Linux build of rxtx not to use lockfiles, or provide the two >> > versions of the lib in the binary archive. >> > >> > Thanks for your indulgence >> > >> > Andy >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> >> >> >> -- >> Atte: >> Daniel Dario Morales Salas >> Ingeniero Civil en Computaci?n e Inform?tica >> Tel?fono: 02 684 3417 >> Celular: 09 643 1802 >> Santiago, Chile > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 WWW: http://www.sharms.org/blog From andy at g0poy.com Wed Feb 3 17:58:29 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 00:58:29 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: <20100204005829.7dc944e1@workstation.site> Thanks Steve, changing the serial ports back the uucp is not a big problem. I have a udev rule that can be easily modified already. However I cannot see any way of dealing with the var/lock problem apart from making it writable to all. Any thoughts? Andy On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms wrote: > This is currently a bug in OpenSUSE that affects more than just rxtx, > and is a result of unified udev rules. You can work around this by > making udev change the group back to uucp until something more > happens. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > Thanks, > > Steve > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > Thanks Daniel, > > > > I am aware of the permissions problem, I have had a udev rules to solve > > this for other programs for some time. > > . > > I don't think that this is the same problem. as far as I can understand > > things, the lock files are written in var/lock. Previously var/lock and > > dev/tty-whatever were the same group. Now with var/lock owned by and with > > a group of root:root anything other than root cannot create a lock > > file. Even minicom is broken by this change. > > > > This change is going to have quite a few knock-on effects I think. > > > > > > Andy > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > Daniel Morales Salas wrote: > > > >> Hi > >> > >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > >> group did not work as it used to be in earlier versions of linux distros, > >> causing RXTX to not work as non root user. > >> > >> The problem appears because the existense of UDEV, now you MUST add a RULE > >> so the group (uucp or whatever) have access (Read, Write, Execute) to the > >> Serial Port. > >> > >> To solve the problem, without needing to recompile RXTX, you must add a rule > >> to grant permissions (0666) to the group for the device or port (tty*, > >> ttyUSB*, etc). I do not remember now what is the line i added but when i > >> come back home i will give it to you (i am at work now). > >> > >> Greetings ! > >> > >> 2010/2/3 > >> > >> > Hello RXTX group, > >> > > >> > I have just joined this group, and this is my first posting. > >> > I wanted to pass on ?some information regarding rxtx, so apologies if > >> > this has been brought up before. I have searched back through the > >> > archives but nothing specific came up. > >> > > >> > I am not a Java programmer, and I only came across rxtx a few days ago. > >> > > >> > I use a piece of test equipment called a miniVNA > >> > http://www.miniradiosolutions.com/ > >> > > >> > This is a serial USB controlled instrument, and it has control software > >> > available for MS windows, and a very old and now non-working Linux > >> > application. > >> > > >> > A few days ago Dietmar, DL2SBA released a Java application to control the > >> > miniVNA, obviously this application makes use of rxtx. > >> > > >> > The program worked fine on Windows, so I set about installing it onto > >> > Linux. I use SUSE11.1 After a few false starts, I got the system running > >> > fairly easily, sorting out the file locking by adding the uucp group to > >> > the users account as suggested (I used the 2.2pre binary files) I then > >> > passed the install instructions onto another miniVNA user, who also uses > >> > SUSE, but he ran into problems. To cut a long story short, he was > >> > also having file lock problems, but the uucp fix did not work. Digging > >> > into his system I found that there have been some changes in SUSE 11.2. > >> > > >> > tty ports are now assigned to the dialout group rather than uucp. > >> > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > >> > checked, so: > >> > > >> > SUSE 11.1, var/lock is root:uucp > >> > SUSE 11.2 var/lock is root:root > >> > > >> > A search on Google brought up several comments regarding this, and also > >> > a ?bugzilla entry. > >> > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > >> > > >> > However from reading the various posts, some of which are in the bugzilla > >> > entry, it appears that many distros may be, or have changed to this > >> > configuration, and this will undoubtedly break several things, rxtx > >> > included. > >> > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the > >> > no lock file option during configure, and that solved his problem. > >> > > >> > As this issue will probably take some time to get resolved across all the > >> > various Linux distros, it might be worth considering changing the default > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > >> > versions of the lib in the binary archive. > >> > > >> > Thanks for your indulgence > >> > > >> > Andy > >> > > >> > _______________________________________________ > >> > Rxtx mailing list > >> > Rxtx at qbang.org > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > >> > >> > >> > >> -- > >> Atte: > >> Daniel Dario Morales Salas > >> Ingeniero Civil en Computaci?n e Inform?tica > >> Tel?fono: 02 684 3417 > >> Celular: 09 643 1802 > >> Santiago, Chile > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > WWW: http://www.sharms.org/blog From damorales at gmail.com Wed Feb 3 18:26:38 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 22:26:38 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100204005829.7dc944e1@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: Hello I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva 2010 this is what i get: drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ and i don't have ANY problem with lock files and RXTX in my java software. All i had to do was add this rule to udev: # serial KERNEL=="tty*", GROUP="uucp", MODE="0666" and that was all. Of course my user (metalklesk) is part of uucp group. I did not make /var/lock writable to all users. Greetings ! 2010/2/3 Andy Eskelson > Thanks Steve, > > changing the serial ports back the uucp is not a big problem. I have a > udev rule that can be easily modified already. However I cannot see any > way of dealing with the var/lock problem apart from making it writable to > all. Any thoughts? > > Andy > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > wrote: > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > and is a result of unified udev rules. You can work around this by > > making udev change the group back to uucp until something more > > happens. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > Thanks, > > > > Steve > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > Thanks Daniel, > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > this for other programs for some time. > > > . > > > I don't think that this is the same problem. as far as I can understand > > > things, the lock files are written in var/lock. Previously var/lock and > > > dev/tty-whatever were the same group. Now with var/lock owned by and > with > > > a group of root:root anything other than root cannot create a lock > > > file. Even minicom is broken by this change. > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > Daniel Morales Salas wrote: > > > > > >> Hi > > >> > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > the uucp > > >> group did not work as it used to be in earlier versions of linux > distros, > > >> causing RXTX to not work as non root user. > > >> > > >> The problem appears because the existense of UDEV, now you MUST add a > RULE > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > the > > >> Serial Port. > > >> > > >> To solve the problem, without needing to recompile RXTX, you must add > a rule > > >> to grant permissions (0666) to the group for the device or port (tty*, > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > i > > >> come back home i will give it to you (i am at work now). > > >> > > >> Greetings ! > > >> > > >> 2010/2/3 > > >> > > >> > Hello RXTX group, > > >> > > > >> > I have just joined this group, and this is my first posting. > > >> > I wanted to pass on some information regarding rxtx, so apologies > if > > >> > this has been brought up before. I have searched back through the > > >> > archives but nothing specific came up. > > >> > > > >> > I am not a Java programmer, and I only came across rxtx a few days > ago. > > >> > > > >> > I use a piece of test equipment called a miniVNA > > >> > http://www.miniradiosolutions.com/ > > >> > > > >> > This is a serial USB controlled instrument, and it has control > software > > >> > available for MS windows, and a very old and now non-working Linux > > >> > application. > > >> > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > control the > > >> > miniVNA, obviously this application makes use of rxtx. > > >> > > > >> > The program worked fine on Windows, so I set about installing it > onto > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > running > > >> > fairly easily, sorting out the file locking by adding the uucp group > to > > >> > the users account as suggested (I used the 2.2pre binary files) I > then > > >> > passed the install instructions onto another miniVNA user, who also > uses > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > >> > also having file lock problems, but the uucp fix did not work. > Digging > > >> > into his system I found that there have been some changes in SUSE > 11.2. > > >> > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > >> > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > >> > checked, so: > > >> > > > >> > SUSE 11.1, var/lock is root:uucp > > >> > SUSE 11.2 var/lock is root:root > > >> > > > >> > A search on Google brought up several comments regarding this, and > also > > >> > a bugzilla entry. > > >> > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > >> > > > >> > However from reading the various posts, some of which are in the > bugzilla > > >> > entry, it appears that many distros may be, or have changed to this > > >> > configuration, and this will undoubtedly break several things, rxtx > > >> > included. > > >> > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > with the > > >> > no lock file option during configure, and that solved his problem. > > >> > > > >> > As this issue will probably take some time to get resolved across > all the > > >> > various Linux distros, it might be worth considering changing the > default > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > >> > versions of the lib in the binary archive. > > >> > > > >> > Thanks for your indulgence > > >> > > > >> > Andy > > >> > > > >> > _______________________________________________ > > >> > Rxtx mailing list > > >> > Rxtx at qbang.org > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > >> > > > >> > > >> > > >> > > >> -- > > >> Atte: > > >> Daniel Dario Morales Salas > > >> Ingeniero Civil en Computaci?n e Inform?tica > > >> Tel?fono: 02 684 3417 > > >> Celular: 09 643 1802 > > >> Santiago, Chile > > > _______________________________________________ > > > Rxtx mailing list > > > Rxtx at qbang.org > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > -- > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > WWW: http://www.sharms.org/blog > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Thu Feb 4 05:31:46 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 12:31:46 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> <20100204005829.7dc944e1@workstation.site> Message-ID: <20100204123146.6cffeb67@workstation.site> Thank's for the confirmation. Something odd is going on somewhere in SUSE 11.2. I'll have to build up a local SUSE11.2 system to see if I can nail down exactly what is going on. Something is blocking the lockfiles in var/lock. The net is nice, but it's a bit difficult trying to work out what is going on what the machine in question is in Germany and I'm in the UK :-) Andy On Wed, 3 Feb 2010 22:26:38 -0300 Daniel Morales Salas wrote: > Hello > > I'm sorry, i am not an expert but if i do an "ls -l /var/lock" on mandriva > 2010 this is what i get: > > drwxr-xr-x 2 root root 4096 2010-02-03 22:11 subsys/ > > and i don't have ANY problem with lock files and RXTX in my java software. > All i had to do was add this rule to udev: > > # serial > KERNEL=="tty*", GROUP="uucp", MODE="0666" > > and that was all. Of course my user (metalklesk) is part of uucp group. > I did not make /var/lock writable to all users. > > Greetings ! > > 2010/2/3 Andy Eskelson > > > Thanks Steve, > > > > changing the serial ports back the uucp is not a big problem. I have a > > udev rule that can be easily modified already. However I cannot see any > > way of dealing with the var/lock problem apart from making it writable to > > all. Any thoughts? > > > > Andy > > > > On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms > > wrote: > > > > > This is currently a bug in OpenSUSE that affects more than just rxtx, > > > and is a result of unified udev rules. You can work around this by > > > making udev change the group back to uucp until something more > > > happens. > > > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > > > Thanks, > > > > > > Steve > > > > > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > > > Thanks Daniel, > > > > > > > > I am aware of the permissions problem, I have had a udev rules to solve > > > > this for other programs for some time. > > > > . > > > > I don't think that this is the same problem. as far as I can understand > > > > things, the lock files are written in var/lock. Previously var/lock and > > > > dev/tty-whatever were the same group. Now with var/lock owned by and > > with > > > > a group of root:root anything other than root cannot create a lock > > > > file. Even minicom is broken by this change. > > > > > > > > This change is going to have quite a few knock-on effects I think. > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > > > Daniel Morales Salas wrote: > > > > > > > >> Hi > > > >> > > > >> I had the same problem in Mandriva 2010 and yes, adding the user to > > the uucp > > > >> group did not work as it used to be in earlier versions of linux > > distros, > > > >> causing RXTX to not work as non root user. > > > >> > > > >> The problem appears because the existense of UDEV, now you MUST add a > > RULE > > > >> so the group (uucp or whatever) have access (Read, Write, Execute) to > > the > > > >> Serial Port. > > > >> > > > >> To solve the problem, without needing to recompile RXTX, you must add > > a rule > > > >> to grant permissions (0666) to the group for the device or port (tty*, > > > >> ttyUSB*, etc). I do not remember now what is the line i added but when > > i > > > >> come back home i will give it to you (i am at work now). > > > >> > > > >> Greetings ! > > > >> > > > >> 2010/2/3 > > > >> > > > >> > Hello RXTX group, > > > >> > > > > >> > I have just joined this group, and this is my first posting. > > > >> > I wanted to pass on some information regarding rxtx, so apologies > > if > > > >> > this has been brought up before. I have searched back through the > > > >> > archives but nothing specific came up. > > > >> > > > > >> > I am not a Java programmer, and I only came across rxtx a few days > > ago. > > > >> > > > > >> > I use a piece of test equipment called a miniVNA > > > >> > http://www.miniradiosolutions.com/ > > > >> > > > > >> > This is a serial USB controlled instrument, and it has control > > software > > > >> > available for MS windows, and a very old and now non-working Linux > > > >> > application. > > > >> > > > > >> > A few days ago Dietmar, DL2SBA released a Java application to > > control the > > > >> > miniVNA, obviously this application makes use of rxtx. > > > >> > > > > >> > The program worked fine on Windows, so I set about installing it > > onto > > > >> > Linux. I use SUSE11.1 After a few false starts, I got the system > > running > > > >> > fairly easily, sorting out the file locking by adding the uucp group > > to > > > >> > the users account as suggested (I used the 2.2pre binary files) I > > then > > > >> > passed the install instructions onto another miniVNA user, who also > > uses > > > >> > SUSE, but he ran into problems. To cut a long story short, he was > > > >> > also having file lock problems, but the uucp fix did not work. > > Digging > > > >> > into his system I found that there have been some changes in SUSE > > 11.2. > > > >> > > > > >> > tty ports are now assigned to the dialout group rather than uucp. > > > >> > > > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > > >> > checked, so: > > > >> > > > > >> > SUSE 11.1, var/lock is root:uucp > > > >> > SUSE 11.2 var/lock is root:root > > > >> > > > > >> > A search on Google brought up several comments regarding this, and > > also > > > >> > a bugzilla entry. > > > >> > > > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > >> > > > > >> > However from reading the various posts, some of which are in the > > bugzilla > > > >> > entry, it appears that many distros may be, or have changed to this > > > >> > configuration, and this will undoubtedly break several things, rxtx > > > >> > included. > > > >> > > > > >> > I solved my fellow SUSE users problem by compiling the rxtx libs > > with the > > > >> > no lock file option during configure, and that solved his problem. > > > >> > > > > >> > As this issue will probably take some time to get resolved across > > all the > > > >> > various Linux distros, it might be worth considering changing the > > default > > > >> > on the Linux build of rxtx not to use lockfiles, or provide the two > > > >> > versions of the lib in the binary archive. > > > >> > > > > >> > Thanks for your indulgence > > > >> > > > > >> > Andy > > > >> > > > > >> > _______________________________________________ > > > >> > Rxtx mailing list > > > >> > Rxtx at qbang.org > > > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > > > >> > > > > >> > > > >> > > > >> > > > >> -- > > > >> Atte: > > > >> Daniel Dario Morales Salas > > > >> Ingeniero Civil en Computaci?n e Inform?tica > > > >> Tel?fono: 02 684 3417 > > > >> Celular: 09 643 1802 > > > >> Santiago, Chile > > > > _______________________________________________ > > > > Rxtx mailing list > > > > Rxtx at qbang.org > > > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > > > -- > > > GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 > > > > > > WWW: http://www.sharms.org/blog > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From Bob_Jacobsen at lbl.gov Thu Feb 4 09:26:49 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Thu, 4 Feb 2010 08:26:49 -0800 Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 Message-ID: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're using RXTX-2.2pre2, although it emits the known message about "Version mismatch". WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 After the usual messing around, we've got it working on 11 Windows versions, multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ have things working rarely say so, so I don't know whether anybody has gotten it to work on 10.4 or not. The problem encountered is this: dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib dyld: Symbol not found: _open$UNIX2003 Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI 2.9.3X/lib/ macosx/librxtxSerial.jnilib Expected in: /usr/lib/libSystem.B.dylib followed by the JVM crashing hard. I've got those dump files if that would help. Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If so, is there a patch I can get and build? Thanks Bob -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From tjarvi at qbang.org Thu Feb 4 14:22:21 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 4 Feb 2010 14:22:21 -0700 (MST) Subject: [Rxtx] Mac OS X 10.4 and RXTX 2.2 In-Reply-To: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> References: <8E966CCE-2AFF-4CFE-A635-391113ED1CA1@lbl.gov> Message-ID: On Thu, 4 Feb 2010, Bob Jacobsen wrote: > We're using RXTX 2.2 on a _very_ cross-platform project. Specifically, we're > using RXTX-2.2pre2, although it emits the known message about "Version > mismatch". > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > > After the usual messing around, we've got it working on 11 Windows versions, > multiple Linuxes, and Mac OS X 10.5 and 10.6. But we're having trouble with > a couple of Mac OS X 10.4 users. Our sociology is such that people who _do_ > have things working rarely say so, so I don't know whether anybody has gotten > it to work on 10.4 or not. > > The problem encountered is this: > > dyld: lazy symbol binding failed: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > dyld: Symbol not found: _open$UNIX2003 > Referenced from: /Data Files/Railway Files/DCC/JMRI/JMRI > 2.9.3X/lib/macosx/librxtxSerial.jnilib > Expected in: /usr/lib/libSystem.B.dylib > > followed by the JVM crashing hard. I've got those dump files if that would > help. > > Is there a known incompatibility between RXTX-2.2pre2 and MacOS X 10.4? If > so, is there a patch I can get and build? > Hi Bob, I talked to a coworker about the problem you ran into. It appears that it is possible to target 'older' Mac systems through makefile configuration changes. "Configuring a Makefile-Based Project If you have a makefile-based project, you can also take advantage of SDK-based development, by adding the appropriate options to your compile and link commands. Using SDKs in makefile-based projects requires GCC 4.0 or later. To choose an SDK, you use the -isysroot option with the compiler and the -syslibroot option with the linker. Both options require that you specify the full path to the desired SDK directory. To set the Deployment OS version in a makefile, use a makefile variable of the form: ENVP= MACOSX_DEPLOYMENT_TARGET=10.4. To use this variable in your makefile, include it in front of your compile and link commands." http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html Or build on the oldest system you want to support. -- Trent Jarvi tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Thu Feb 4 14:56:19 2010 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Thu, 4 Feb 2010 14:56:19 -0700 Subject: [Rxtx] RXTX on 64 Bit Redhat In-Reply-To: References: <4ec9eab61001281448g3dd84910r867619948a4e0d7a@mail.gmail.com> Message-ID: Trent -- Finally fixed all my build related issues. I ran into another issue. On one of my machines my JDK is returning multiple folders for the "java.ext.dirs" (java.ext.dirs -> /opt/jdk1.6.0_17/jre/lib/ext:/usr/java/packages/lib/ext) system property. As a result my JVM wasn't able to detect the gnu.io.rxtx.properties. I am attaching a patch for RXTXCommDriver.java file to check for multiple locations. Also i have to assign permission 660 to all my dev ports to be located by RXTX. Pawan ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 5:12 PM To: Trent Jarvi Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Here is the error i get when i build the src from release-2-1-7 -bash-3.2$ make ( \ \ cd i686-pc-linux-gnu; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/ jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I/opt/jav a1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec - c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialImp.lo;\ if [ "Serial" = "Serial" ]; then \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=compile gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/include -I /opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_tim espec -c /home/jb_stg/rxtx/rxtx-devel/./src/fuserImp.c -o \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo \ /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/fuserImp. lo; \ else \ /bin/sh /home/jb_stg/rxtx/rxtx-devel/libtool --mode=link gcc -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need_timespec -lpthread -release 2.1-7 -o librxtxSerial.la -rpath /home/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/SerialIm p.lo; \ fi; \ ) gcc -I/home/jb_stg/rxtx/rxtx-devel -Ii686-pc-linux-gnu -I. -I/opt/java1.6/inclu de -I/opt/java1.6/include/./linux/ -g -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D__need _timespec -c /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c -fPIC -DPIC -o /hom e/jb_stg/rxtx/rxtx-devel/i686-pc-linux-gnu/.libs/SerialImp.o /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:25:29: error: gnu_io_RXTXPort.h: No such file or directory In file included from /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.c:113: /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:91: error: expected specifier-qua lifier-list before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'JNIEnv' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:407: error: expected declaration specifiers or '...' before 'jobject' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:408: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:409: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:410: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:411: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:415: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:416: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:417: error: expected '=', ',', '; ', 'asm' or '__attribute__' before 'is_interrupted' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:418: error: expected declaration specifiers or '...' before 'jint' /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:424: error: expected ')' before ' *' token /home/jb_stg/rxtx/rxtx-devel/./src/SerialImp.h:441: error: expected ')' before ' *' token ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kharbanda, Pawan Sent: Thursday, January 28, 2010 4:57 PM To: Santosh Cc: rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat Santosh -- Thank you. That fixed the issue. All -- What CVS branch or release should i use to get the latest RXTX src code. Pawan ________________________________ From: Santosh [mailto:santosh.ry at gmail.com] Sent: Thursday, January 28, 2010 3:49 PM To: Kharbanda, Pawan Cc: Trent Jarvi; rxtx at qbang.org Subject: Re: [Rxtx] RXTX on 64 Bit Redhat error "./configure: /bin/sh^M: bad interpreter: No such file or directory". I think you need to run dos2unix on script files before compiling. Thanks, Santosh On Thu, Jan 28, 2010 at 5:33 PM, Kharbanda, Pawan > wrote: Trent -- We are upgrading our exisiting OS and JDK on a project that rely heavily on RXTX api's. We are now using JDK1.6 32 bit (build 1.6.0_17-b04) and RedHat 5 on a 64 bit machine. Linux tocrhstg02.dot.state.co.us 2.6.18-164.6.1.el5 #1 SMP Tue Oct 27 11:30:06 EDT 2009 i686 i686 i386 GNU/Linux Red Hat Enterprise Linux Server release 5.4 (Tikanga) I tried to run version 2.1.7 r2 on it but not able to see any of my Digi ports I was able to access only /dev/ttyS0 (physical ports). Not sure if the problem is with the Digi driver or RXTX. I tried to open a Digi port with minicom and it worked fine. I also tried to get latest from CVS (rxtx-devel) and when I do "configure" I see this error "./configure: /bin/sh^M: bad interpreter: No such file or directory". Can someone please help me with this? Thanks for the help. Pawan _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch.txt URL: From juan.vicente.l.g at gmail.com Sat Feb 13 04:44:17 2010 From: juan.vicente.l.g at gmail.com (Juan Vicente Lopez Gutierrez) Date: Sat, 13 Feb 2010 12:44:17 +0100 Subject: [Rxtx] RXTX in macmini OSX 10.5 Message-ID: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> Hello. My name is Juanvi and I'm from Spain. I tried to launch a software created by me in the library CXR java to send information through the serial port and I can not make it work. In windows if I've done but not mac. I have a mac mini with OSX 10.5 and have read in the list of web mail that you CXR if you have managed to make it work on that operating system. I need you help me please. Do I make the mistake that shows me java: run: Stable Library =============================== Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 gnu.io.PortInUseException: Unknow Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:26) at TwoWatSerialComm.main(TwoWaySerialComm.java:106) Experimental: JNI_OnLoad called. GENERACION CORRECTA (total time: 0 seconds) I do not have permission to access the serial port, do not know. Os agradeceria much to sit down. A greeting and thanks. Pardon my English. Juanvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From juan.vicente.l.g at gmail.com Sat Feb 13 14:39:41 2010 From: juan.vicente.l.g at gmail.com (Juan Vicente Lopez Gutierrez) Date: Sat, 13 Feb 2010 22:39:41 +0100 Subject: [Rxtx] Fwd: RXTX in macmini OSX 10.5 In-Reply-To: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> References: <29405e5c1002130344k7ad6d21dxf38934b0989bb8c5@mail.gmail.com> Message-ID: <29405e5c1002131339m2059d169sdc8549ed9706a1af@mail.gmail.com> ---------- Forwarded message ---------- From: Juan Vicente Lopez Gutierrez Date: 2010/2/13 Subject: RXTX in macmini OSX 10.5 To: rxtx at qbang.org Hello. My name is Juanvi and I'm from Spain. I tried to launch a software created by me in the library CXR java to send information through the serial port and I can not make it work. In windows if I've done but not mac. I have a mac mini with OSX 10.5 and have read in the list of web mail that you CXR if you have managed to make it work on that operating system. I need you help me please. Do I make the mistake that shows me java: run: Stable Library =============================== Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 gnu.io.PortInUseException: Unknow Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:26) at TwoWatSerialComm.main(TwoWaySerialComm.java:106) Experimental: JNI_OnLoad called. GENERACION CORRECTA (total time: 0 seconds) I do not have permission to access the serial port, do not know. Os agradeceria much to sit down. A greeting and thanks. Pardon my English. Juanvi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Mon Feb 22 04:35:48 2010 From: george.dma at gmail.com (George H) Date: Mon, 22 Feb 2010 13:35:48 +0200 Subject: [Rxtx] Lingering rxtx process Message-ID: Hi, I am using RXTX v2.1-7. I use it to communicate with 2 serial receipt printers and 1 serial line display device. My program runs well using the RXTX library on Windows and Linux. But... when I installed Linux on another hardware the program does not exit properly. By this I mean that the java program seems to have exited (passed the System.exit(0)) code but the console still does not return to the bash shell. I have to CTRL+C each time to kill the program. And on each restart RXTX has to remove stale LCK files. Just note I am only getting this on one machine, if it makes any difference it is an i686 system with all VIA chipsets and VIA-C7M NannoBGA2 processor. Any ideas? Thanks -- George H george.dma at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Mon Feb 22 04:43:43 2010 From: george.dma at gmail.com (George H) Date: Mon, 22 Feb 2010 13:43:43 +0200 Subject: [Rxtx] Lingering rxtx process Message-ID: Hi, I am using RXTX v2.1-7. I use it to communicate with 2 serial receipt printers and 1 serial line display device. My program runs well using the RXTX library on Windows and Linux. But... when I installed Linux on another hardware the program does not exit properly. By this I mean that the java program seems to have exited (passed the System.exit(0)) code but the console still does not return to the bash shell. I have to CTRL+C each time to kill the program. And on each restart RXTX has to remove stale LCK files. Just note I am only getting this on one machine, if it makes any difference it is an i686 system with all VIA chipsets and VIA-C7M NannoBGA2 processor. Any ideas? Thanks -- George H george.dma at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Tue Feb 23 01:29:42 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Tue, 23 Feb 2010 09:29:42 +0100 Subject: [Rxtx] Lingering rxtx process In-Reply-To: References: Message-ID: <73a89f361002230029w4a9ec14bt56d654e43c1c9623@mail.gmail.com> 2010/2/22 George H > Hi, > > I am using RXTX v2.1-7. > I use it to communicate with 2 serial receipt printers and 1 serial line > display device. My program runs well using the RXTX library on Windows and > Linux. > But... when I installed Linux on another hardware the program does not exit > properly. By this I mean that the java program seems to have exited (passed > the System.exit(0)) code but the console still does not return to the bash > shell. > > Thread in Noember 2009' - http://mailman.qbang.org/pipermail/rxtx/2009-November/5778408.html I have disocvered one technique which solved this problem in Linux Ubuntu and Mac for RXTX pre2.2, but should helps in 2.1.7 as well. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Thu Feb 25 02:41:46 2010 From: george.dma at gmail.com (George H) Date: Thu, 25 Feb 2010 11:41:46 +0200 Subject: [Rxtx] Lingering rxtx process In-Reply-To: <73a89f361002230029w4a9ec14bt56d654e43c1c9623@mail.gmail.com> References: <73a89f361002230029w4a9ec14bt56d654e43c1c9623@mail.gmail.com> Message-ID: With Mariusz Dec help and with the help of the threads that were mentioned http://mailman.qbang.org/pipermail/rxtx/2009-November/5790326.html http://embeddedfreak.wordpress.com/2008/10/08/rxtx-serial-port-helper/ I managed to solved my problem. I didn't really like it so much. I am not using the InputStream.read(byte[], int, int) method as for me I can break out of reading the stream if I get a '\n' or a 0x00. Either way the below code sample works for me. int data = 0; int len = 0; while(true) { data = commReader.getInputStream().read(); if(data == -1 || data == 0x00 || data == '\n' || commReader.getInputStream().available() < 1) { break; } if(len == buffer.length) { processData(buffer); clearBuffer(); } buffer[len++] = (byte)data; } Before I would loop the while until data != -1. But that blocks on .close() and my program never gets to exit. Adding .available() < 1 as a break condition fixes it when I call .close() I am going to see if this is a linux kernel configuration issue or not cos it isn't so obvious and I hardly ever use .available() when reading streams. Love the project though :) -- George H george.dma at gmail.com On Tue, Feb 23, 2010 at 10:29 AM, Mariusz Dec wrote: > > > 2010/2/22 George H > > Hi, >> >> I am using RXTX v2.1-7. >> I use it to communicate with 2 serial receipt printers and 1 serial line >> display device. My program runs well using the RXTX library on Windows and >> Linux. >> But... when I installed Linux on another hardware the program does not >> exit properly. By this I mean that the java program seems to have exited >> (passed the System.exit(0)) code but the console still does not return to >> the bash shell. >> >> Thread in Noember 2009' - > > http://mailman.qbang.org/pipermail/rxtx/2009-November/5778408.html > > I have disocvered one technique which solved this problem in Linux Ubuntu > and Mac for RXTX pre2.2, but should helps in 2.1.7 as well. > > Regards > Mariusz > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 01:02:21 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 13:32:21 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> My serial port driver(apparently) does not support receive timeout.I registered an event listener for DATA_AVAILABLE. However, the control never seems to come out of the 'while' loop.Shouldn't the InputStream.read return a '-1' immediately if no data is available (this seems to be the default operation)? This was tried on a x86 Linux desktop using rxtx-2.1-7 I've added the snippet for clarity: /******************************************************************************************************************************************************************************/ mySerialPort.enableReceiveThreshold(2000);//Trying to set a time limit for read calls System.out.println(mySerialPort.isReceiveTimeoutEnabled()); // I get FALSE, so its not supported on hardware. mySerialPort.addEventListener(this); mySerialPort.notifyOnDataAvailable(true);//register a event with //my SerialEvent listener implementation: public void serialEvent(SerialPortEvent arg0) { int newData=0; switch(arg0.getEventType()){ case SerialPortEvent.DATA_AVAILABLE: while (newData != -1) { try { newData = is.read();//This should eventually return a -1 if no data is available within a timeout.PROBLEM!! System.out.println("Got a byte from port:"+newData); if (newData == -1) { break; } } catch (IOException ex) { System.err.println(ex); return; } } break; } return; } /******************************************************************************************************************************************************************************/ Thanks and regards, Ravi From michael.erskine at ketech.com Wed Feb 3 02:26:50 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 09:26:50 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From michael.erskine at ketech.com Wed Feb 3 05:03:30 2010 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 3 Feb 2010 12:03:30 +0000 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD22E@aimail.automotiveinfotronics.com> Message-ID: > Michael Erskine > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > > Your event handler should handle the event and return immediately so that its > controlling thread can handle other events. I recommend a single read in the > following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) > reads all available bytes up to the size of the buffer returning the number of > bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } After posting this I considered the glaring possibility of the rawbuf read buffer being too small to receive all the available bytes and perhaps skipping data: after all, I'm guessing that is why we see so many posts asking for help with blocking implementations of read event handlers looping on "while(bytes are available)". I've spent this morning writing an extensive multi-threaded unit test suite that includes tests with a tiny buffer compared to the amount of data available and found that no data was being skipped. I now want to know why! The SerialPortEvent.DATA_AVAILABLE event must be being fired again if there is more data available on the input stream. If that is the case then it should be heavily documented with good examples in the wiki to avoid the types of developer anguish we see so regularly. BTW: I'm not at liberty to post the JUnit tests as they use my company's unit test suite framework. Regards, Michael Erskine. From Ravishankar.N at automotiveinfotronics.com Wed Feb 3 06:18:04 2010 From: Ravishankar.N at automotiveinfotronics.com (Ravishankar N) Date: Wed, 3 Feb 2010 18:48:04 +0530 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Hello Michael, I tried out your suggestion but the problem is that the read(rawbuf) blocks until the entire length of the rawbuf array has been read (blocking). I cannot decide on a reasonable size of the array because it varies from 2 bytes to as much as 50 byes (i'm communicating with a modem,each response is of a different length), which is why i wanted to use non blocking calls. But on a side note, read(byte[]) in turn calls the read() in a loop.In the native C function, the read is supposed to return a -1 upon timeout.But my driver does not support timeout.The default timeout value is zero and the linux select call upon zero time out causes an infinite wait.What am i missing...... Thanks and regards, Ravi Date: Wed, 3 Feb 2010 09:26:50 +0000 From: Michael Erskine To: "rxtx at qbang.org" Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? Message-ID: Content-Type: text/plain; charset="us-ascii" > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Ravishankar N > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > My serial port driver(apparently) does not support receive timeout.I > registered an event listener for DATA_AVAILABLE. However, the control never > seems to come out of the 'while' loop.Shouldn't the > InputStream.read return a '-1' immediately if no data is available (this seems > to be the default operation)? Your event handler should handle the event and return immediately so that its controlling thread can handle other events. I recommend a single read in the following manner: rawbuf is a byte[] of "reasonable" size and the read(byte[]) reads all available bytes up to the size of the buffer returning the number of bytes actually read... case SerialPortEvent.DATA_AVAILABLE: try { int i = is.read(rawbuf); if (i == -1) { << process EOF condition - should never happen >> return; } << process bytes (rawbuf, i); >> return; } catch (IOException e) { << promptly deal with exception >> return; } This style of reading has worked for me with RXTX on Linux and Windows XP for a good few years now in railway industry communications systems. Any timeouts (largely unnecessary in my applications) can be handled elsewhere, usually at a higher layer. Regards, Michael Erskine. From m.kirkland at comcast.net Wed Feb 3 06:46:03 2010 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 3 Feb 2010 05:46:03 -0800 Subject: [Rxtx] One port blocking another port In-Reply-To: References: Message-ID: <68768633814F4D7D86761D34F0764FE0@bengal.net> It turns out this is caused by having the RTS/CTS flow control turned on and me not providing a true on the RTS pin. Somehow it seems the port timing out on a read allows the write to proceed. This is not an issue for my application but I wonder if the write should not proceed until the RTS pin is true even if a read times out. mk -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Monday, January 25, 2010 7:48 PM To: Mike Kirkland Cc: rxtx at qbang.org Subject: Re: [Rxtx] One port blocking another port On Mon, 25 Jan 2010, Mike Kirkland wrote: > > Hi All, > > ? > > I have a program that reads from one com port and writes to another com > port. It also does the same thing in reverse (reads from the second com port > and writes to the first one. It basically ties two com ports together. > > ? > > One port is very chatty and has a consent stream of data. The other port has > very little data. > > ? > > Both ports use a 5000 ms (5 second) time out. > > ? > > The issue I am having is that is appears that the first port?s write to the > second port is blocked while the second port is waiting for input. The first > port?s write proceeds only after the second port has timed out. > > ? > > I suppose I could have something twisted around in my code but I was > wondering if this is a know issue? > Hi Kirk, I've not seen a report like this. Perhaps some simple reproduction code will reveal a problem on your end or help us identify a problem in rxtx. I think there are several users doing multiport communication. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Wed Feb 3 07:03:58 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:03:58 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> Message-ID: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> 2010/2/3 Ravishankar N > Hello Michael, > [..] > But on a side note, read(byte[]) in turn calls the read() in a loop.In the > native C function, the read is supposed to return a -1 upon timeout.But my > driver > does not support timeout.The default timeout value is zero and the linux > select call upon zero time out causes an infinite wait.What am i > missing...... > > When I have tested RXTX between platforms, I have observed "hangup" inside JNI driver when no data in Linux, is normal thing. Solution was setting the timeout for RXTX when no data from JNI driver. Something like that: commPort.enableReceiveTimeout(10); And it works perfect.... The only difference is that I am NOT using events - I am using continous read in separate thread and if data is available, is parsed and transferred to application using exception. Regards Mariusz > Thanks and regards, > Ravi > > Date: Wed, 3 Feb 2010 09:26:50 +0000 > From: Michael Erskine > To: "rxtx at qbang.org" > Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? > Message-ID: > > > Content-Type: text/plain; charset="us-ascii" > > > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of > > Ravishankar N > > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? > > > > My serial port driver(apparently) does not support receive timeout.I > > registered an event listener for DATA_AVAILABLE. However, the control > never > > seems to come out of the 'while' loop.Shouldn't the > > InputStream.read return a '-1' immediately if no data is available (this > seems > > to be the default operation)? > > Your event handler should handle the event and return immediately so that > its controlling thread can handle other events. I recommend a single read in > the following manner: rawbuf is a byte[] of "reasonable" size and the > read(byte[]) reads all available bytes up to the size of the buffer > returning the number of bytes actually read... > > case SerialPortEvent.DATA_AVAILABLE: > try { > int i = is.read(rawbuf); > if (i == -1) { > << process EOF condition - should never happen >> > return; > } > << process bytes (rawbuf, i); >> > return; > } catch (IOException e) { > << promptly deal with exception >> > return; > } > > This style of reading has worked for me with RXTX on Linux and Windows XP > for a good few years now in railway industry communications systems. Any > timeouts (largely unnecessary in my applications) can be handled elsewhere, > usually at a higher layer. > > Regards, > Michael Erskine. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Feb 3 07:22:55 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 3 Feb 2010 09:22:55 -0500 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: I'm guessing that this is driver specific. I recently had to support a select()/poll() infrastructure for a linux serial DD, its certainly non trivial to support async IO, so I suspect the problem in this case has to do with missing poll infrastructure in the device driver. This also has to coupled with special open flags for the device (which is within the rxtx code) The key routines within a 2.6 kernel linux device driver are shown below (if you have access to it for your particular device) are indicated below (here is a snippet from my device driver c code that supports polling/select). User space code to test this shown below also, note that the device needs to be opened with the O_NONBLOCK option to support the select/poll api // device driver code ..... /* * File operations supported by this driver. */ static struct file_operations iop_fops = { .owner = THIS_MODULE, .check_flags= iop_check_flags, .ioctl = iop_ioctl, .open = iop_open, .poll = iop_poll, // SUPPORT FOR SELECT/POLL infrastructure .read = iop_read, .release = iop_release, .write = iop_write, }; /** * Select/poll/epoll infrastructure. * * @param file * @param wait * * @return */ static unsigned int iop_poll(struct file *filp, poll_table *wait) { struct iop_device *devp = (struct iop_device *)filp->private_data; // the poll_table wait arg is an opaque pointer poll_wait(filp, &devp->readq, wait); // return from poll indicating whether we have read/write data unsigned int mask = 0; if (kfifo_len(devp->rx_fifo)) { mask |= (POLLIN | POLLRDNORM); } // @JC We don't do select on write yet // if (kfifo_len(devp->tx_fifo)) { // mask |= (POLLOUT | POLLWRNORM); // } // Only print out while debugging // if (mask != 0) { // printk (KERN_INFO "%s: [%04x]\n", __FUNCTION__, mask); // } return mask; } /** * device driver blocking and non blocking read function. This * function reads the requested number of bytes from the read * kfifo blocking as required. * * @param filp * @param buf * @param count * @param f_pos * * @return */ static ssize_t iop_read(struct file *filp, char __user *buf, size_t count, loff_t * ppos) { // access appropriate device struct struct iop_device *devp = (struct iop_device *) filp->private_data; ssize_t retval; // support non blocking mode (default) by checking if the kfifo is empty first if ((kfifo_len(devp->rx_fifo)==0) && (filp->f_flags & O_NONBLOCK)) { return -EAGAIN; } // wait for rx_fifo to receive data via receive interrupts retval = wait_event_interruptible(devp->readq, kfifo_len(devp->rx_fifo) != 0); // check for some error condition if (retval) { printk (KERN_ERR "%s: wait_event_interruptible returned[%d]\n", __FUNCTION__, retval); return retval; } // copy max requested bytes from rx_fifo to device buffer // this may still leave bytes in the kfifo for a subsequent read // if we are reading in a loop retval = kfifo_get(devp->rx_fifo, devp->rxbuf, count); // printk (KERN_INFO "%s: [%d] byte(s)\n", __FUNCTION__, retval); if (copy_to_user(buf, devp->rxbuf, retval)) { printk (KERN_ERR "%s: problem copying rx_fifo data to user buffer\n", __FUNCTION__); return -EFAULT; } return retval; } // a selection of my user space code reading via select()/poll()..... // user space open code iop_fd = ::open( deviceName.data(), O_RDWR | O_NONBLOCK); while ((bytes_to_expect - bytes_read) > 0) { // must reinitialize these between select calls fd_set readfds; FD_ZERO( &readfds ); FD_SET( iop_fd, &readfds ); // 1s sec read polling timeout struct timeval timeout; timeout.tv_sec = 1; timeout.tv_usec = 0; int rc = select( FD_SETSIZE, &readfds, NULL, NULL, &timeout ); // read from file when descriptor // indicates data available without blocking if ((rc > 0) && FD_ISSET(iop_fd, &readfds)) { // read into the appropriate offset within the rx_buf int temp = read(iop_fd, rx_buf + bytes_read, bytes_to_expect - bytes_read); if (!temp) { printf("EOF detected with %d bytes expected\n", bytes_to_expect - bytes_read); } else { bytes_read += temp; } } else if (rc < 0){ printf("%s: select on [%s], bytes_read[%d], errno=%d\n", __FUNCTION__, thread_args->device, bytes_read, errno); } else { printf("%s: select on [%s], bytes_read[%d], timeout\n", __FUNCTION__, thread_args->device, bytes_read); } } On Wed, Feb 3, 2010 at 9:03 AM, Mariusz Dec wrote: > > > 2010/2/3 Ravishankar N > >> Hello Michael, >> [..] >> >> But on a side note, read(byte[]) in turn calls the read() in a loop.In the >> native C function, the read is supposed to return a -1 upon timeout.But my >> driver >> does not support timeout.The default timeout value is zero and the linux >> select call upon zero time out causes an infinite wait.What am i >> missing...... >> >> > When I have tested RXTX between platforms, I have observed "hangup" inside > JNI driver when no data in Linux, is normal thing. > > Solution was setting the timeout for RXTX when no data from JNI driver. > > Something like that: > > commPort.enableReceiveTimeout(10); > > And it works perfect.... > > The only difference is that I am NOT using events - I am using continous > read in separate thread and if data is available, is parsed and transferred > to application using exception. > > Regards > Mariusz > > > >> Thanks and regards, >> Ravi >> >> Date: Wed, 3 Feb 2010 09:26:50 +0000 >> From: Michael Erskine >> To: "rxtx at qbang.org" >> Subject: Re: [Rxtx] Non-blocking InputStream.read ()-How to? >> Message-ID: >> >> >> Content-Type: text/plain; charset="us-ascii" >> >> > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >> Of >> > Ravishankar N >> > Subject: [Rxtx] Non-blocking InputStream.read ()-How to? >> > >> > My serial port driver(apparently) does not support receive timeout.I >> > registered an event listener for DATA_AVAILABLE. However, the control >> never >> > seems to come out of the 'while' loop.Shouldn't the >> > InputStream.read return a '-1' immediately if no data is available (this >> seems >> > to be the default operation)? >> >> Your event handler should handle the event and return immediately so that >> its controlling thread can handle other events. I recommend a single read in >> the following manner: rawbuf is a byte[] of "reasonable" size and the >> read(byte[]) reads all available bytes up to the size of the buffer >> returning the number of bytes actually read... >> >> case SerialPortEvent.DATA_AVAILABLE: >> try { >> int i = is.read(rawbuf); >> if (i == -1) { >> << process EOF condition - should never happen >> >> return; >> } >> << process bytes (rawbuf, i); >> >> return; >> } catch (IOException e) { >> << promptly deal with exception >> >> return; >> } >> >> This style of reading has worked for me with RXTX on Linux and Windows XP >> for a good few years now in railway industry communications systems. Any >> timeouts (largely unnecessary in my applications) can be handled elsewhere, >> usually at a higher layer. >> >> Regards, >> Michael Erskine. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Feb 3 07:33:27 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 3 Feb 2010 15:33:27 +0100 Subject: [Rxtx] Non-blocking InputStream.read ()-How to? In-Reply-To: References: <3E7F2F2A885AA84997FE3DFF6C2B101F6912CBD231@aimail.automotiveinfotronics.com> <73a89f361002030603i5a313180if06bddbdcf4d4309@mail.gmail.com> Message-ID: <73a89f361002030633j682610afia48dc7accd8e049b@mail.gmail.com> 2010/2/3 John Coffey > I'm guessing that this is driver specific. I recently had to support a > select()/poll() infrastructure for a linux serial DD, its certainly non > trivial to support async IO, so I suspect the problem in this case has to do > with missing poll infrastructure in the device driver. This also has to > coupled with special open flags for the device (which is within the rxtx > code) > > Yes, you are right, it may be driver specific, but in my case I haven't changed blocking JNI driver. I have added ONLY one call to RXTX method mentioned in my previous post and blocking (as seen as from Java app) gone out... Maybe this is not elegant, but works without problem in my app. I am using only FTDI chips and their drivers from couple of years and maybe this is the kind of the way to have no many problems with serial as well? Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From andyrxtx at g0poy.co.uk Wed Feb 3 11:09:04 2010 From: andyrxtx at g0poy.co.uk (andyrxtx at g0poy.co.uk) Date: Wed, 3 Feb 2010 18:09:04 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes Message-ID: <20100203180904.164f24dd@workstation.site> ?Hello RXTX group, I have just joined this group, and this is my first posting. I wanted to pass on some information regarding rxtx, so apologies if this has been brought up before. I have searched back through the archives but nothing specific came up. I am not a Java programmer, and I only came across rxtx a few days ago. I use a piece of test equipment called a miniVNA http://www.miniradiosolutions.com/ This is a serial USB controlled instrument, and it has control software available for MS windows, and a very old and now non-working Linux application. A few days ago Dietmar, DL2SBA released a Java application to control the miniVNA, obviously this application makes use of rxtx. The program worked fine on Windows, so I set about installing it onto Linux. I use SUSE11.1 After a few false starts, I got the system running fairly easily, sorting out the file locking by adding the uucp group to the users account as suggested (I used the 2.2pre binary files) I then passed the install instructions onto another miniVNA user, who also uses SUSE, but he ran into problems. To cut a long story short, he was also having file lock problems, but the uucp fix did not work. Digging into his system I found that there have been some changes in SUSE 11.2. tty ports are now assigned to the dialout group rather than uucp. A hint in the rxtx INSTALL file, suggested that var/lock needs to be checked, so: SUSE 11.1, var/lock is root:uucp SUSE 11.2 var/lock is root:root A search on Google brought up several comments regarding this, and also a bugzilla entry. https://bugzilla.novell.com/show_bug.cgi?id=552095 However from reading the various posts, some of which are in the bugzilla entry, it appears that many distros may be, or have changed to this configuration, and this will undoubtedly break several things, rxtx included. I solved my fellow SUSE users problem by compiling the rxtx libs with the no lock file option during configure, and that solved his problem. As this issue will probably take some time to get resolved across all the various Linux distros, it might be worth considering changing the default on the Linux build of rxtx not to use lockfiles, or provide the two versions of the lib in the binary archive. Thanks for your indulgence Andy From damorales at gmail.com Wed Feb 3 11:33:23 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Wed, 3 Feb 2010 15:33:23 -0300 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203180904.164f24dd@workstation.site> References: <20100203180904.164f24dd@workstation.site> Message-ID: Hi I had the same problem in Mandriva 2010 and yes, adding the user to the uucp group did not work as it used to be in earlier versions of linux distros, causing RXTX to not work as non root user. The problem appears because the existense of UDEV, now you MUST add a RULE so the group (uucp or whatever) have access (Read, Write, Execute) to the Serial Port. To solve the problem, without needing to recompile RXTX, you must add a rule to grant permissions (0666) to the group for the device or port (tty*, ttyUSB*, etc). I do not remember now what is the line i added but when i come back home i will give it to you (i am at work now). Greetings ! 2010/2/3 > Hello RXTX group, > > I have just joined this group, and this is my first posting. > I wanted to pass on some information regarding rxtx, so apologies if > this has been brought up before. I have searched back through the > archives but nothing specific came up. > > I am not a Java programmer, and I only came across rxtx a few days ago. > > I use a piece of test equipment called a miniVNA > http://www.miniradiosolutions.com/ > > This is a serial USB controlled instrument, and it has control software > available for MS windows, and a very old and now non-working Linux > application. > > A few days ago Dietmar, DL2SBA released a Java application to control the > miniVNA, obviously this application makes use of rxtx. > > The program worked fine on Windows, so I set about installing it onto > Linux. I use SUSE11.1 After a few false starts, I got the system running > fairly easily, sorting out the file locking by adding the uucp group to > the users account as suggested (I used the 2.2pre binary files) I then > passed the install instructions onto another miniVNA user, who also uses > SUSE, but he ran into problems. To cut a long story short, he was > also having file lock problems, but the uucp fix did not work. Digging > into his system I found that there have been some changes in SUSE 11.2. > > tty ports are now assigned to the dialout group rather than uucp. > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > checked, so: > > SUSE 11.1, var/lock is root:uucp > SUSE 11.2 var/lock is root:root > > A search on Google brought up several comments regarding this, and also > a bugzilla entry. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > However from reading the various posts, some of which are in the bugzilla > entry, it appears that many distros may be, or have changed to this > configuration, and this will undoubtedly break several things, rxtx > included. > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > no lock file option during configure, and that solved his problem. > > As this issue will probably take some time to get resolved across all the > various Linux distros, it might be worth considering changing the default > on the Linux build of rxtx not to use lockfiles, or provide the two > versions of the lib in the binary archive. > > Thanks for your indulgence > > Andy > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Wed Feb 3 12:07:02 2010 From: andy at g0poy.com (Andy Eskelson) Date: Wed, 3 Feb 2010 19:07:02 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> Message-ID: <20100203190702.1b0e7015@workstation.site> Thanks Daniel, I am aware of the permissions problem, I have had a udev rules to solve this for other programs for some time. . I don't think that this is the same problem. as far as I can understand things, the lock files are written in var/lock. Previously var/lock and dev/tty-whatever were the same group. Now with var/lock owned by and with a group of root:root anything other than root cannot create a lock file. Even minicom is broken by this change. This change is going to have quite a few knock-on effects I think. Andy On Wed, 3 Feb 2010 15:33:23 -0300 Daniel Morales Salas wrote: > Hi > > I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > group did not work as it used to be in earlier versions of linux distros, > causing RXTX to not work as non root user. > > The problem appears because the existense of UDEV, now you MUST add a RULE > so the group (uucp or whatever) have access (Read, Write, Execute) to the > Serial Port. > > To solve the problem, without needing to recompile RXTX, you must add a rule > to grant permissions (0666) to the group for the device or port (tty*, > ttyUSB*, etc). I do not remember now what is the line i added but when i > come back home i will give it to you (i am at work now). > > Greetings ! > > 2010/2/3 > > > Hello RXTX group, > > > > I have just joined this group, and this is my first posting. > > I wanted to pass on some information regarding rxtx, so apologies if > > this has been brought up before. I have searched back through the > > archives but nothing specific came up. > > > > I am not a Java programmer, and I only came across rxtx a few days ago. > > > > I use a piece of test equipment called a miniVNA > > http://www.miniradiosolutions.com/ > > > > This is a serial USB controlled instrument, and it has control software > > available for MS windows, and a very old and now non-working Linux > > application. > > > > A few days ago Dietmar, DL2SBA released a Java application to control the > > miniVNA, obviously this application makes use of rxtx. > > > > The program worked fine on Windows, so I set about installing it onto > > Linux. I use SUSE11.1 After a few false starts, I got the system running > > fairly easily, sorting out the file locking by adding the uucp group to > > the users account as suggested (I used the 2.2pre binary files) I then > > passed the install instructions onto another miniVNA user, who also uses > > SUSE, but he ran into problems. To cut a long story short, he was > > also having file lock problems, but the uucp fix did not work. Digging > > into his system I found that there have been some changes in SUSE 11.2. > > > > tty ports are now assigned to the dialout group rather than uucp. > > > > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > > checked, so: > > > > SUSE 11.1, var/lock is root:uucp > > SUSE 11.2 var/lock is root:root > > > > A search on Google brought up several comments regarding this, and also > > a bugzilla entry. > > > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > > > However from reading the various posts, some of which are in the bugzilla > > entry, it appears that many distros may be, or have changed to this > > configuration, and this will undoubtedly break several things, rxtx > > included. > > > > I solved my fellow SUSE users problem by compiling the rxtx libs with the > > no lock file option during configure, and that solved his problem. > > > > As this issue will probably take some time to get resolved across all the > > various Linux distros, it might be worth considering changing the default > > on the Linux build of rxtx not to use lockfiles, or provide the two > > versions of the lib in the binary archive. > > > > Thanks for your indulgence > > > > Andy > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile From thisdyingdream at gmail.com Wed Feb 3 12:32:35 2010 From: thisdyingdream at gmail.com (Steven Harms) Date: Wed, 3 Feb 2010 14:32:35 -0500 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: <20100203190702.1b0e7015@workstation.site> References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: This is currently a bug in OpenSUSE that affects more than just rxtx, and is a result of unified udev rules. You can work around this by making udev change the group back to uucp until something more happens. https://bugzilla.novell.com/show_bug.cgi?id=552095 Thanks, Steve On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > Thanks Daniel, > > I am aware of the permissions problem, I have had a udev rules to solve > this for other programs for some time. > . > I don't think that this is the same problem. as far as I can understand > things, the lock files are written in var/lock. Previously var/lock and > dev/tty-whatever were the same group. Now with var/lock owned by and with > a group of root:root anything other than root cannot create a lock > file. Even minicom is broken by this change. > > This change is going to have quite a few knock-on effects I think. > > > Andy > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > Daniel Morales Salas wrote: > >> Hi >> >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp >> group did not work as it used to be in earlier versions of linux distros, >> causing RXTX to not work as non root user. >> >> The problem appears because the existense of UDEV, now you MUST add a RULE >> so the group (uucp or whatever) have access (Read, Write, Execute) to the >> Serial Port. >> >> To solve the problem, without needing to recompile RXTX, you must add a rule >> to grant permissions (0666) to the group for the device or port (tty*, >> ttyUSB*, etc). I do not remember now what is the line i added but when i >> come back home i will give it to you (i am at work now). >> >> Greetings ! >> >> 2010/2/3 >> >> > Hello RXTX group, >> > >> > I have just joined this group, and this is my first posting. >> > I wanted to pass on ?some information regarding rxtx, so apologies if >> > this has been brought up before. I have searched back through the >> > archives but nothing specific came up. >> > >> > I am not a Java programmer, and I only came across rxtx a few days ago. >> > >> > I use a piece of test equipment called a miniVNA >> > http://www.miniradiosolutions.com/ >> > >> > This is a serial USB controlled instrument, and it has control software >> > available for MS windows, and a very old and now non-working Linux >> > application. >> > >> > A few days ago Dietmar, DL2SBA released a Java application to control the >> > miniVNA, obviously this application makes use of rxtx. >> > >> > The program worked fine on Windows, so I set about installing it onto >> > Linux. I use SUSE11.1 After a few false starts, I got the system running >> > fairly easily, sorting out the file locking by adding the uucp group to >> > the users account as suggested (I used the 2.2pre binary files) I then >> > passed the install instructions onto another miniVNA user, who also uses >> > SUSE, but he ran into problems. To cut a long story short, he was >> > also having file lock problems, but the uucp fix did not work. Digging >> > into his system I found that there have been some changes in SUSE 11.2. >> > >> > tty ports are now assigned to the dialout group rather than uucp. >> > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be >> > checked, so: >> > >> > SUSE 11.1, var/lock is root:uucp >> > SUSE 11.2 var/lock is root:root >> > >> > A search on Google brought up several comments regarding this, and also >> > a ?bugzilla entry. >> > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 >> > >> > However from reading the various posts, some of which are in the bugzilla >> > entry, it appears that many distros may be, or have changed to this >> > configuration, and this will undoubtedly break several things, rxtx >> > included. >> > >> > I solved my fellow SUSE users problem by compiling the rxtx libs with the >> > no lock file option during configure, and that solved his problem. >> > >> > As this issue will probably take some time to get resolved across all the >> > various Linux distros, it might be worth considering changing the default >> > on the Linux build of rxtx not to use lockfiles, or provide the two >> > versions of the lib in the binary archive. >> > >> > Thanks for your indulgence >> > >> > Andy >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> >> >> >> -- >> Atte: >> Daniel Dario Morales Salas >> Ingeniero Civil en Computaci?n e Inform?tica >> Tel?fono: 02 684 3417 >> Celular: 09 643 1802 >> Santiago, Chile > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 WWW: http://www.sharms.org/blog From andy at g0poy.com Wed Feb 3 17:58:29 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 4 Feb 2010 00:58:29 +0000 Subject: [Rxtx] Linux lock files - problems due to distro changes In-Reply-To: References: <20100203180904.164f24dd@workstation.site> <20100203190702.1b0e7015@workstation.site> Message-ID: <20100204005829.7dc944e1@workstation.site> Thanks Steve, changing the serial ports back the uucp is not a big problem. I have a udev rule that can be easily modified already. However I cannot see any way of dealing with the var/lock problem apart from making it writable to all. Any thoughts? Andy On Wed, 3 Feb 2010 14:32:35 -0500 Steven Harms wrote: > This is currently a bug in OpenSUSE that affects more than just rxtx, > and is a result of unified udev rules. You can work around this by > making udev change the group back to uucp until something more > happens. > > https://bugzilla.novell.com/show_bug.cgi?id=552095 > > Thanks, > > Steve > > On Wed, Feb 3, 2010 at 2:07 PM, Andy Eskelson wrote: > > Thanks Daniel, > > > > I am aware of the permissions problem, I have had a udev rules to solve > > this for other programs for some time. > > . > > I don't think that this is the same problem. as far as I can understand > > things, the lock files are written in var/lock. Previously var/lock and > > dev/tty-whatever were the same group. Now with var/lock owned by and with > > a group of root:root anything other than root cannot create a lock > > file. Even minicom is broken by this change. > > > > This change is going to have quite a few knock-on effects I think. > > > > > > Andy > > > > > > > > > > > > On Wed, 3 Feb 2010 15:33:23 -0300 > > Daniel Morales Salas wrote: > > > >> Hi > >> > >> I had the same problem in Mandriva 2010 and yes, adding the user to the uucp > >> group did not work as it used to be in earlier versions of linux distros, > >> causing RXTX to not work as non root user. > >> > >> The problem appears because the existense of UDEV, now you MUST add a RULE > >> so the group (uucp or whatever) have access (Read, Write, Execute) to the > >> Serial Port. > >> > >> To solve the problem, without needing to recompile RXTX, you must add a rule > >> to grant permissions (0666) to the group for the device or port (tty*, > >> ttyUSB*, etc). I do not remember now what is the line i added but when i > >> come back home i will give it to you (i am at work now). > >> > >> Greetings ! > >> > >> 2010/2/3 > >> > >> > Hello RXTX group, > >> > > >> > I have just joined this group, and this is my first posting. > >> > I wanted to pass on ?some information regarding rxtx, so apologies if > >> > this has been brought up before. I have searched back through the > >> > archives but nothing specific came up. > >> > > >> > I am not a Java programmer, and I only came across rxtx a few days ago. > >> > > >> > I use a piece of test equipment called a miniVNA > >> > http://www.miniradiosolutions.com/ > >> > > >> > This is a serial USB controlled instrument, and it has control software > >> > available for MS windows, and a very old and now non-working Linux > >> > application. > >> > > >> > A few days ago Dietmar, DL2SBA released a Java application to control the > >> > miniVNA, obviously this application makes use of rxtx. > >> > > >> > The program worked fine on Windows, so I set about installing it onto > >> > Linux. I use SUSE11.1 After a few false starts, I got the system running > >> > fairly easily, sorting out the file locking by adding the uucp group to > >> > the users account as suggested (I used the 2.2pre binary files) I then > >> > passed the install instructions onto another miniVNA user, who also uses > >> > SUSE, but he ran into problems. To cut a long story short, he was > >> > also having file lock problems, but the uucp fix did not work. Digging > >> > into his system I found that there have been some changes in SUSE 11.2. > >> > > >> > tty ports are now assigned to the dialout group rather than uucp. > >> > > >> > A hint in the rxtx INSTALL file, suggested that var/lock needs to be > >> > checked, so: > >> > > >> > SUSE 11.1, var/lock is root:uucp > >> > SUSE 11.2 var/lock is root:root > >> > > >> > A search on Google brought up several comments regarding this, and also > >> > a ?bugzilla entry. > >> > > >> > https://bugzilla.novell.com/show_bug.cgi?id=552095 > >> > > >> > However from reading the various posts, some of which are in the bugzilla > >> > entry, it appears that many distros may be, or have changed to this > >>