If I have a pseudo terminal given to me (from say a pty-req (http://www.ietf.org/rfc/rfc4254.txt)) do I need to emulate the data coming back, or is that already emulated data?
It depends on the level of emulation you're talking about. The pty uses the remote server's terminal driver, so options controlled by stty (and the analogous system calls) will be emulated there.
But you're running an application that sends terminal control escape sequences, you'll need to handle that locally.
Related
I developed an ElectronJS app that, on startup, opens a BrowserWindow on each available monitor. It works correctly as long as all monitors are configured on same display (display 0).
If I configure some monitors as display 0 and some others as display 1, the latter are not seen by the app and BrowserWindows are created only for the former.
I searched the documentation but I haven't found anything about how multiple display configuration is managed (or if it is not supported).
Is there any option (or workaround) to allow the app to see display 1 monitors?
TL;DR: X11 is not designed to work this way.
As this answer over at Unix & Linux SE indicates, only a single display per X server is supported. Thus, you'd have to spawn multiple X servers to get multiple displays -- and explicitly specifying devices to use is known to be problematic as my X11 configuration files have disclaimers like "Having multiple Device sections is known to be problematic" linking to this bug at X11's bugtracker.
Furthermore, the environment variable DISPLAY determines which X display is to be used by applications. Try echo $DISPLAY in a shell of your choice; it will most likely output :0, which is display 0. At not point at runtime can an X11 application decide that it wants to communicate with another X server, because it cannot determine if another one is present (or to what display address it would be listening). It only knows (from DISPLAY) which one it should be talking to.
Another point to make is that you cannot have the same desktop session running across multiple X servers without going to great lengths (see the above linked answer). Also, I do not think that even this would be possible with all desktop environments, as KDE Plasma for example binds to one specific X server (to be able to handle its own set of monitor configurations).
My employer has asked me to prepare for testing several thousand Chromebooks (mix of models/manufacturers) to refurb/flip. This may be a recurring thing.
Most or all of these will be old enough that CCD will not be available. I'd like to connect a widget such as a Raspberry Pi to the USB and have it automate testing as much as possible.
I know I can use keyboard emulation to inject commands, but I'd like to get a crosh session running over USB so that I can read info from the DUT besides just controlling it.
Google shows bazillions of returns about using a Chromebook as an ssh terminal but what I'm looking for is the opposite. I'm prepared for the answer to be a simple "no" but I'm concerned because I can't find that anyone else has asked this question. I don't think I'm that creative, so I suspect my Goog-fu is weak.
The answer appears to be "no". However I solved it another way; using "gadget mode" I have a Raspberry Pi ZW enumerate as a keyboard and a serial port. I put the Chromebook into Developer mode, open a developer shell with ctrl/alt/F2, or on a PC/linux or Mac system open a terminal window and type "sudo su" (these have to be done manually). Then I have the RPi issue this bash command to identify the serial port "in the blind":
SERPORT=/dev/serial/by-id/$(ls /dev/serial/by-id) # Chromebook or PC/linux
(or)
SERPORT=$(ls /dev/cu.usbmodem*) # Mac
Now I can have the RPi inject commands via the keyboard, put ">$SERPORT" on the end of each command, and the output comes in the RPi gadget serial port. The RPi then packages the data and forwards it over WiFi to our CRM. It's working nicely for Chromebooks, PCs booted into linux, Mac desktops and Macbooks.
Edit:
The company I work for has actually turned this into a product and so I'm not sure how much detail I should share, but...
I learned my way around gadget mode on the RPi from this link. There are examples for setting up a keyboard and a serial port. Using the templates in that link, I made a device called /dev/hidg0 which emits keyboard scancodes from the RPi to the Chromebook. I also made a device called /dev/ttyGS0 which the Chromebook sees as a serial port.
So I send keystrokes with some python like:
with open("/dev/hidg0","bw") as hid:
hid.write(blah)
and then have the Chromebook send text to the serial port, which I then read by looking at /dev/ttyGS0
Hopefully this will be enough to get you started. I found the isticktoit link very helpful.
Is there a simple way to implement communication between two computers running GNUradio using the standard blocks set?
What I am have now is this:
On a Linux computer, GNUradio is running and receiving input from a Radio peripheral. On that computer I can see the received waveform on a WX scope. I can also use sliders and input boxes to change things like the receiver frequency.
What I'd like to do is this:
On a Windows computer, I have the WX scope and sliders. When I move the a slider or change an input box, that data gets sent to the Linux, which is still running the radio receiver on Gnuradio. The received signal goes through a stream back to the windows, and gets displayed on the WX scope on Windows.
Someone elsewhere suggested using the ZMQ blocks, however, when I tried setting up a PUSH/PULL to transmit a sine wave from the Linux to the Windows, nothing went through. The guy who recommended that approach tried the same and also could not get it working, so I think that block might be broken?
So is there any alternative blocks that can do what I'm trying to do? Preferably something well documented, and available on GNUradio-companion.
Depending on the data rate from the receiver, it's possible to encounter performance issues attempting to send raw waveform data using e.g. the UDP blocks, where the sender may print an error similar to the following:
gr::log :WARN: udp_source0 - Too much data; dropping packet.
Because the scope widgets usually only display a portion of the input data, a more ideal way of remotely visualizing the waveform might be to only send the rendered scope widget (e.g. using a remote desktop such as VNC or X2Go). Although this solution reaches beyond your original problem, it is probably easier to use in the long run for cases involving two-way GUI interaction.
For the scope widget data, the UDP sink and source blocks seem to be native to GNU Radio, and are either sufficiently documented solution or simple enough for this problem, again taking firewall configuration into consideration as #Zephyr mentioned.
From GRC, specify in the UDP blocks:
the hostname or IP address of the display computer, and
a choose port number that isn't already in use (and were you using Linux, OS X, or anything UNIX-like, not any port below 1024).
For setting variables over the network, you might try the XMLRPC blocks, as described in another answer. These were recently deprecated, however.
See my other answer for discussion of alternative if performance issues arise.
Both Linux and Windows should have firewalls which might be blocking the connections.
You need to post the error messages displayed in gnuradio-companion.
My Bixolon SRP-350II is not shown in the list of available devices given by
posExplorer.GetDevices();
All I see are Microsoft's simulated devices. The printer itself works, I can print on it and, using raw printing, send commands such as "cut". I've installed the OPOS driver for the printer, but nothing changed.
Is it necessary to do some further configuration? Is the order of installing POS.NET, the OPOS-driver and the Windows driver important?
Alright, figured out the Printer had to be configured with PSPLauncher.exe and now it shows up. Still, I am not sure I understand where exactly the benefit of POS .NET lies. I want the customers to plug-in new printers and when using Raw Printing and EscPos-commands, this seems to be much easier.
Plug printer in, install windows driver, set to main printer and then cut-commands etc. are being send in the raw stream.
I can't say directly for printers, but where we get the benefits out of POS.NET is the standard code we wrote for the scanners, or MSRs or cash drawers. All we have to do is install the driver, and configure the device in OPOS configuration (which is probably the step you were missing and resolved with the "PSPLauncher.exe") and we know that it's code-compatible and just works.
We have hundreds of terminals across the country (Australia) and they all use a variety of models and brands for the devices (within a range of tolerance) but because of POS.NET they're all supported.
Further to my previous question, I find that I cannot use the GExpertsDebugWindow on a PC which did not previously have Delphi installed.
If I have the following (not unusal, so probably of interest to others) requirements, do I need to roll my own code or is there and existing and free solution?
Must be able to read acorss the network (i.e., PC 1 monitors PC 2's debug output) by specifying PC 2's IP address
If posible, I would like to be able to filter by process name
Thanks in advance for any help
Microsoft's DebugView tool has those features. It can display OutputDebugString output, even from remote systems. Depending on other factors, it can even install itself remotely.