I'm developing app with qt4 (c++) for Linux platform. When I'm using QTextDocument::drawContext method(), sometimes (not always) printer is printing some junks and wasting a lot of paper. I think it can be related with printer driver. This is Oki MicroLine 3390 eco printer. This printer is emulating EPSON LQ driver.
I have tested few epson drivers but that did not help at all. I cannot fix this issue so I have started looking for some alternative solution - write directly to device.
I'm looking for info:
How to write raw data (formatted text) to usb dot matrix printer?
is any one know how to fix printing issue?
any write command will do print on device /dev/usb/lp0
test it # cat [file] > /dev/usb/lp0
Try to send reset sequence before printing process:
[ write_2_printer("\x1b\x40");]
Related
Is there a way with pyusb to unbind a USB device?
I know using the following bash the USB is unbound.
DEVICE=$(grep 064f /sys/bus/usb/devices/*/idVendor | tr '/' ' ' | awk '{ print $5 }')
/bin/bash -c "echo $DEVICE >/sys/bus/usb/drivers/usb/unbind"
But for various reasons I like to move away from bash and switch to Python, and ideally avoid maintaining my custom, complicated logic. So using a existing library makes sense to me.
Selected answer in stackoverflow.com#q54863367 suggests detach_kernel_driver to work for this purpose, but I don't see that happening on my environment; It does unmount the volume in the designated USB device (confirmed by watching the disk space on the USB disappears in lsblk's output) but I still see that OS detects the USB device.
$ ipython
In [7]: import usb
...: dev = usb.core.find(idVendor=0x064f, idProduct=0x03f3)
In [8]: dev.detach_kernel_driver(0)
$ watch lsusb
:
Bus 002 Device 043: ID 064f:03f3 WIBU-Systems AG CmStick/M (article no. 1011)
Environment
Linux (At the time of writing, Ubuntu 16.04 (I know EoLed) or 18.04. But environment shouldn't be a limiting factor. Open for available solutions regardless the version.
UPDATE: My usecase requires mimicing removal of USB device. We've been happy with the operation typically called as un/bind, and also happy with the bash solution to realize un/bind.
A quick search of the PyUSB code makes it seem like there is no feature for binding or unbinding. So PyUSB is not the answer.
However, you don't need to use Bash to unbind a device. Python has a standard library that lets you get directory listings, read files, and write to files, so you can just use Python's standard library instead of Bash.
Thought I'd close OP but coudln't choose an appripriate reason so answer by myself instead.
As I concluded myself with a help from the maintainer in pyusb#399 I found I was misunderstood. Using detach_kernel_driver as suggested in stackoverflow.com#q54863367 worked for my purpose as well.
I'm trying to send files over a half-duplex interface (RS-485) between a box PC running debian (4.19) and a SBC with an im6xDL.
Thanks to this community I can successfully transfer simple data between the units using picocom or by echoing/reading.
The box PC supports half-duplex RS-485 natively and has automatic RTS functions so that you can read/send data without any issue. The SBC on the other hand needs to be toggled to change into RX or TX mode.
This turned out to be a problem when I tried to send files from the box PC to the SBC.
On the box PC:
picocom /dev/ttyUSB0 -b 9600 -fn
C-a,C-S
***file: /home/user/test.txt
Transfer incomplete
*** exit status: 128
On the SBC
picocom /dev/ttymxc2 -b 9600 -fn -et
C-a,C-r
Terminal ready
�000000
As you can see something is terribly wrong, it is like it cannot interpret the bits when a file is being transferred.
My questions:
Is it possible to send files from the command line in half-duplex systems? (The SBC needs to be in RX mode the entire time).
Is there another way to achieve this that is more intuitive?
As always, thanks for the help and support :)
/W
See here:
Pymodbus - Read input register of Energy meter over rs485 on uart of raspberry pi3
The solution I presented there using pylibmodbus should work for any hardware with UART and one or two GPIO lines accessible from user space in Linux.
If, on the other hand, what you want to do is use something like picocom or minicom then you can take a look at the hardware-only solution using a 555 timer.
Of course, if prototyping circuits is not for you, you can always buy a USB to RS485 with half-duplex support. You have many available but those based on the MAX13487 IC seem to work very well.
EDIT: The solution using the 555 timer is not in the post I linked above but here together with some more background material on half-duplex RS485 links: RS485: Inappropriate ioctl for device
I'm writing to a centronics cable and blinking some LEDs via a simple "bufferized" circuit.
I'm able to write out the bits via C code referencing the device location on /dev/usb/lp0 on an Ubuntu machine.
However, I'd like to be able to do this on OSX Mavericks. I don't see the same type of device file as I do in Linux.
i.e. is there an OSX analog to /dev/usb/lp0 on Linux?
Thanks much.
Under the concept of "everything's a file" lp0 is just a special file that allows raw access to a device, in this case a 'special character file' for the first parallel device. The same would exist on OSX if a driver was present that matched the device, or something like /dev/parport0. OSX has a pretty limited collection of parallel drivers though. You could try to fudge it - create a 'character' device file pointing it to some generic parallel driver with mknod.
e.g. mknod lp0 c x y where x an y are the major and minor numbers for the device type. Typically you find these numbers in the documentation/devices.txt file on linux, not sure where this info is on OSX though.
I've seen devices handle this using generic printer drivers, such as a "gadget printer":
https://www.kernel.org/doc/Documentation/usb/gadget_printer.txt
(my initial assumption)
In this case the device will actually show up on the system as a printer. You can find a list of printers and their location using CUPS utilities like lpstat:
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/lpstat.1.html#//apple_ref/doc/man/1/lpstat
There's also the environment variables LPDEST and PRINTER which should list the default print location:
echo $LDPEST
I was wondering how is it possible to capture a video from a usb camera device connected to my linux machine with c++ and the terminal alone or perhaps a bash script, i see the terminal but i dont think an echo would provide me with video or frames. Help would be extremely appreciated.
Thank you
Give a look at this page . The v4l2grab is a program that reads raw images and convert them to jpeg and is run in a terminal
Does anyone know of a good way to get a bi-directional dump of MIDI SysEx data on Linux? (between a Yamaha PSR-E413 MIDI keyboard and a copy of the Yamaha MusicSoft Downloader running in Wine)
I'd like to reverse-engineer the protocol used to copy MIDI files to and from my keyboard's internal memory and, to do that, I need to do some recording of valid exchanges between the two.
The utility does work in Wine (with a little nudging) but I don't want to have to rely on a cheap, un-scriptable app in Wine when I could be using a FUSE filesystem.
Here's the current state of things:
My keyboard connects to my PC via a built-in USB-MIDI bridge. USB dumpers/snoopers are a possibility, but I'd prefer to avoid them if possible. I don't want to have to decode yet another layer of protocol encoding before I even get started.
I run only Linux. However, if there really is no other option than a Windows-based dumper/snooper, I can try getting the USB 1.1 pass-through working on my WinXP VirtualBox VM.
I run bare ALSA for my audio system with dmix for waveform audio mixing.
If a sound server is necessary, I'm willing to experiment with JACK.
No PulseAudio please. It took long enough to excise it from my system.
If the process involves ALSA MIDI routing:
a virtual pass-through device I can select from inside the Downloader is preferred because it often only appears in an ALSA patch bay GUI like patchage an instant before it starts communicating with the keyboard.
Neither KMIDIMon nor GMIDIMonitor support snooping bi-directionally as far as I can tell.
virmidi isn't relevant and I haven't managed to get snd-seq-dummy working.
I I suppose I could patch ALSA to get dumps if I really must, but it's really an option of last resort.
The vast majority of my programming experience is in Python, PHP, Javascript, and shell script.
I have almost no experience programming in C.
I've never even seen a glimpse of kernel-mode code.
I'd prefer to keep my system stable and my uptime high.
This question has been unanswered for some time and while I do not have an exact answer to your problem I maybe have something that can push you in the right direction (or maybe others with similar problems).
I had a similar albeit less complex problem when I wanted to sniff the data used to set and read presets on an Akai LPK25 MIDI keyboard. Similar to your setup the software to setup the keyboard can run in Wine but I also had no luck in finding a sniffer setup for Linux.
For the lack of an existing solution I rolled my own using ALSA MIDI routing over virmidi ports. I understand why you see them as useless because without additional software they cannot help at sniffing MIDI traffic.
My solution was programming a MIDI relay/bridge in Java where I read input from a virmidi port, display the data and send it further to the keyboard. The answer from the keyboard (if any) is also read, displayed and finally transmitted back to the virmidi port. The application in Wine can be setup to use the virmidi port for communication and in theory this process is completely transparent (except for potential latency issues). The application is written in a generic way and not hardcoded to my problem.
I was only dealing with SysEx messages of about 20 bytes length so I am not sure how well the software works for sniffing the transfer of large amounts of data. But maybe you can modify it / write your own program following the example.
Sources available here: https://github.com/hiben/MIDISpy
(Java 1.6, ant build file included, source is under BSD license)
I like using aseqdump for that.
http://www.linuxcommand.org/man_pages/aseqdump1.html
You could use virtual midi devices for this purpose. So you have to load snd_seq_dummy so that it creates at least two ports:
$ sudo modprobe -r snd_seq_dummy
$ sudo modprobe snd_seq_dummy ports=1 duplex=1
Then you should have a device named Midi through:
$ aconnect -i -o -l
client 0: 'System' [type=kernel]
0 'Timer '
1 'Announce '
client 14: 'Midi Through' [type=kernel]
0 'Midi Through Port-0:A'
1 'Midi Through Port-0:B'
client 131: 'VMPK Input' [type=user,pid=50369]
0 'in '
client 132: 'VMPK Output' [type=user,pid=50369]
0 'out '
I will take the port and device numbers form this example. You have to inspect them yourself according to your setup.
Now you plug your favourate MIDI Device to the Midi Through ports:
$ aconnect 132:0 14:0
$ aconnect 14:0 131:0
At this time you have a connection where you can spy on both devices at the same time. You could use aseqdump to spy the MIDI conversation. There are different possibilities. I suggest to spy the connection between the loopback devices and the real device. This allows you for rawmidi connections to the loopback devices.
$ aseqdump -p 14:0,132:0 | tee dump.log
Now everything is set up for use. You just have to be careful about port names in your MIDI application. It should read MIDI data from Midi Through Port-0:B and write data to Midi Through Port-0:B.
Some additional hint: You could use the graphical frontend patchage for connecting and inspecting the MIDI connections via drag and drop. If you do this you will see that every Midi Through port occurs twice once as input and once as output. Both have to be connected in order to make this setup work.
If you want to use GMidiMonitor or some other application you spy on both streams intermixed (without showing the direction) using aconnect suppose 129:0 is the Midi Monitor port :
$ aconnect 14:0 129:0
$ aconnect 132:0 129:0
If you want to have exact direction information you could add another GMidiMonitor instance that you connect only to one of the ports. The missing messages come from the other port.
What about using gmidimonitor? See http://home.gna.org/gmidimonitor/