Thanks for this fast answer, Le mercredi 16 mars 2016 à 19:13 +0100, Stephen Kitt a écrit :
Hi Yvan,On Wed, 16 Mar 2016 18:21:18 +0100, [email protected] wrote: > > First, please apologize: I don't know if what I experience is > really a > bug or just me that do not understand how to use this tool. Perhaps a bit of both ;-). > > I am trying to use an Orbit MS7120 barcode scanner (RS232), which > works > well using "cat /dev/ttyS0". So I take it you'd like to use inputattach so that the barcode scanner is treated like a keyboard, is that correct?
Exactly
> > # inputattach -lk /dev/ttyS0 > -> writes garbage in every windows -> works as expected because > the > "mode" is not the right one By "every windows", do you mean that scanning something causes characters to be sent to all windows simultaneously, or do they go to the window which has focus, whichever it is?
Indeed I have not been clear: they go to the window which has focus, whichever it is.
> > # inputattach --daemon -lk /dev/ttyS0 > -> same as before but daemonize -> works as expected > > # inputattach --baud 9600 --dump /dev/ttyS0 > -> writes good scanned data only to the current terminal -> I > suppose it > should also write to other terminals / windows > Sample output: > 30 (0) 35 (5) 31 (1) 31 (1) 32 (2) 32 (2) 31 (1) 39 (9) > 39 (9) 33 (3) 33 (3) 32 (2) 0d (x) 0a (x) This is as expected. The documentation for --dump is misleading (I'll fix that...): instead of attaching the device to the input subsystem, it dumps the characters it receives in the format above. It's intended for debugging new devices. In this instance I take it you scanned the barcode for 051122199332...
That is what I suspected.
> > # inputattach --daemon --baud 9600 --dump /dev/ttyS0 > -> same as before, but never goes to background -> I suppose it > should > daemonize --daemon is effectively ignored in --dump mode. (I'll document that too.) > > Also, the last 2 commands do NOT add an entry in > /proc/bus/input/devices. That's expected (but undocumented). > > All of that makes me think that the "dump" "mode" is only for > testing > purposes. > Am I right? If so, what to do if other "modes" are not correct for > this > peripheral? That is correct. As far as I'm aware there isn't an appropriate mode for your device...
I can only trust you, but this looks really weird: This missing mode would be the simplest as it seems to only need attaching to device subsystem. Do you agree with this supposition ?
Adding a new mode requires support in the kernel and inputattach. Since it would be useful generally, I'll add a feature to inputattach so new modes can be tried using command-line parameters, then you can try to find a mode which works ;-).
It would be nice !
Alternatively, you may have more luck with https://launchpad.net/seri al-text which continuously reads input from a serial port and injects it into the input subsystem. If that works I can perhaps add it to the inputattach package, or package it directly.
Thanks for your proposition, but infortunately it seems there is no code published, see https://answers.launchpad.net/serial-text/+question /102154 I must also tell you that I already tried another software called softwedge (https://github.com/theatrus/softwedge). I have read only success reports with it, but it did not work for me ("Can't open serial port: ttyS0") and I can't read C code find the reason... It is sad, but unless you have another idea, you can close this "bug". As Loye Young said on Launchpad: "It's a program everyone thinks is already written, but isn't." Thanks for your time and work, Yvan
signature.asc
Description: PGP signature
