I've got a Raspberry Pi connected to my TV, with no mouse or keyboard.
I'm sshing into it, starting X and then I want to launch VLC (or any other GUI program, for that matter). If I ssh -X, that will open the program in the computer I'm sshing from, not on the TV.
How can I launch a program and make it appear on the TV?
Slightly less typing than Joachim's (and actually slightly different behavior):
DISPLAY=:0 vlc
This doesn't actually set the DISPLAY variable to :0 for the whole shell session, only passes it to vlc.
So:
If you want to start other X programs in that session after VLC, Joachim's is better.
If you just want to run VLC ASAP, this is faster by 9 keypresses. :)
(I wanted to add this only as a comment, but I didn't have enough points for that, sorry.)
The DISPLAY environment variable needs to have a value set to which display the program should be opened. If you set it to :0, it means the first local screen.
This should in other words open vlc on the first local screen;
export DISPLAY=:0 ; vlc
Related
Using XTERM control sequences (specifically CSI ?1000h), I can get notified on stdin any time the user clicks on the terminal window. Unfortunately this also means I get notified if the scroll wheel is spun, instead of normal terminal scrolling taking place. Is there any way to, preferably easily and simply, just get notified about clicks and nothing else?
Alternatively, is there a way to send an escape sequence that the terminal emulator will interpret as "oh, you want me to scroll normally"? I'd be (reluctantly) okay with having to parse all the mouse commands, and then if I notice a scroll-up signal (button 96 or 64 depending on mode), echo it back saying "here, terminal, you handle this one". In theory these should be the scroll-forw and scroll-back actions, but I haven't found a way to use these directly.
If it makes any difference, I'm using xfce4-terminal, but am willing to try other terminal emulators if it would help with debugging this.
The X10 protocol sends only clicks (no wheel mouse). That's documented. But that's for xterm.
VTE (checking just now with XFCE Terminal) differs from xterm by sending wheel-mouse events. VTE has no documentation worth mentioning, aside from its source-code (ymmv).
The scroll-forw and scroll-back actions are xterm features, for which there are no counterparts in VTE.
I have a problem with my new bluetooth HC-05 module. In AT-mode it works perfectly with all commands that I need... exept INQ.
I have tried to send whole bunch of other commands beforehand:
AT+INIT
OK
AT+ORGL
OK
AT+ROLE=1
OK
AT+CLASS=0
OK
They all are working just fine. I tried to change IAC and INQM settings as well... but the answer from module is always the same:
AT+INQ
ERROR:(1F)
I read related topic here and tried to push the button at HC-05, as it recommended there, but -- no result either.
I have three modules from the same shop, and they all are working the same way
I have a HC-05 with 3.0-20170601 that I managed to bind to a slave last night. It turns out that the v3 has two AT-modes.
The first is when you hold the button while you connect power. The led will blink slowly and you can connect at 38400 baud. But this is like a configuration mode, where AT+INQ is not available.
In this mode I did these commands:
AT
AT+UART
AT+RMAAD
AT+ROLE=1
(Press and hold the button)
AT+RESET
(Release the button after device restarts and led is slowly blinking)
AT+CMODE=1
AT+INQM=0,5,5
AT+PSWD="9999"
AT should give OK as answer to know connection is working
AT+UART will show configured baudrate. Default is 9600.
AT+RMAAD clears all saved connections
AT+ROLE=1 sets it as master
AT+RESET restarts the device to change to master
AT+CMODE=1 accepts all kinds of devices
AT+INQM=0,5,5 inquires in standard mode, with 5 max connections or 5 secs
AT+PSWD="9999" sets the pin code 9999, change to the pin you need
After this it is time to update the arudino code so that it connects to the configured baud rate. It will be something like
BTSerial.begin(9600);
...or what ever value you might have set the baud rate to. Then reflash your arduino.
Now enter the very irritating second AT command mode.
Power up without holding the button. You will get the fast blink speed. When its powered up, press and hold the button. The led will continue blinking fast, but while the button is pressed you can now connect to the device on the configured baud rate. So open the serial monitor and type AT to verify.
Remember that the mode is only active while the button is pressed. So keep it pressed. I had a small clamp I put on there.
Then I entered these commands:
AT+STATE
AT+STATE will show current state, should be inquiring
Then power up the slave device and the adress should start popping up. It will be something like xyz:xy:xyzw,931F00,7FFF
The first part is the address you want (xyz:xy:xyzw)
Change : to , and get xyz,xy,xyzw
Check that you connecting to the correct device
AT+RNAME?xyz,xy,xyzw
Then bind
AT+PAIR=xyz,xy,xyzw,5
AT+BIND=xyz,xy,xyzw
AT+LINK=xyz,xy,xyzw
The AT+LINK command gave me FAIL as output. But it did not matter.
I restarted and did not press any button before or after. Just normal start.
After 5-10s serial data showed up in my serial monitor.
Modules are bound. And will automatically connect at power up. If not you might have the wrong pincode. Make sure to change 9999 above to 0000 or 1234 or what ever it may be. When I hade the wrong pin I still got OK from the AT+PAIR and AT+BIND commands... It didnt work for me until I entered the correct pin.
Sorry for long post, but I wanted to be thorough since info about HC-05 v3 is very scarce on the internet right now.
A reference to all commands can be found here:
http://www.electronicaestudio.com/docs/istd016A.pdf
(Link valid 2018-08-13)
We have same problem and you can see the answer in here.
The conclusion of problem is about the firmware on HC-05 you use. If you use firmware version 3.0, you will get error 1F in AT+INQ. Maybe HC-05 with firmware version 3.0 has different parameters to run AT+INQ. Now I'm confused about how to find HC-05 with firmware version 2.0. That HC-05 have push button or not.
In short, the answer is: The (B) module with firmware version 2.0-20100601 works ok with the following commands (set PIN34 high at power-up, or press button on module and keep pressed during commands).
So HC-05 with version 2.0 use push button or not, it's the same.
If you have some information about the different between HC-05 version 3.0 and version 2.0, please let me know.
This is on Ubuntu. I have two xsessions, one on tty7 (display :0) and one on tty8 (display :1). For the record, :0 is Unity and :1 is Fluxbox. I would like to be able to take a screenshot on display :1 while working on display :0.
I'm using the Java Robot class. I've written a small screen scraping bot. The mouse movements work when I'm switched to the other virtual terminal, but the screengrabs are coming out all black (the bot has no image to act on).
I'm spawning the second xsession with:
startx /usr/bin/fluxbox -- :1
Is there a way to make the screenshots work? Is there a workaround for keeping the display active (remote desktop to it?)? Would someone be kind enough to explain why these go black when the virtual terminal is not focused?
I'm looking for the least intensive way to have a second display, mouse, and keyboard running. The path of least resistance would be a way to keep the display active when not focused.
Thanks! Sorry if any of my terminology is off, new to using a second virtual terminal.
You get a black image simply because the image you want to capture does not exist anywhere.
When a virtual terminal is active, each program that is on your display will generate its own image, and the image gets put into the video memory. When the virtual terminal is not active, the programs do not generate their image (since it would be superfluous), nothing stores those images, so you cannot capture them.
I'm configuring GNU screen in a cygwin environment. Re-configuring actually--it always just worked before, and when I upgraded to cygwin-64 the same config files give me unexpected behavior.
What happens is that whenever I do something in the terminal that overflows a full screen the terminal does not scroll. Instead, each new line "overwrites" the last one on the bottom row of the window. Even when the process is through, if I CTRL+l, there's a bunch of garbage left on the last three lines of the terminal. Also, when I use a program that takes up the entire screen, such as vim or irssi, the "caption" line disappears.
I suspect that there's some discrepancy between my xterm settings and screen's 'term' setting, but I'm a little at sea here and, as I said, all the same configuration files worked fine (and do work fine on other machines--both cygwin and native linux). Can anyone recommend a way to get my beloved screen to behave again?
Here's my .screenrc:
shell /bin/bash
screen -t bash 0
select 0
escape ^Zz # Instead of Control-a, make the escape/command character be Control-z
autodetach on # Autodetach session on hangup instead of terminating screen completely
startup_message off # Turn off the splash screen
defscrollback 30000 # Use a 30000-line scrollback buffer
nethack on
# Misc h4x to make scrollback work
terminfo * te#:ti#
termcapinfo xterm|xterms|xs|rxvt ti=\E7\E[?47l
# Bells are annoying
bell_msg ''
vbell off
caption always '%{= kG}[ %{G}%H %{g}][%= %{= kw}%?%-Lw%?%{r}(%{W}%n*%f%t%?(%u)%?%{r})%{w}%?%+Lw%?%?%= %{g}][%{B} %d/%m %{W}%c %{g}]'
You're running screen under xterm (something I do all the time myself). The screen process "knows" how big the terminal is, but that information can be out of sync with reality. I find this happens a lot when I run screen -dr from a different window.
Resizing the xterm windows causes it to send a SIGWINCH signal to the process running under it, which typically causes that process to re-query the tty settings.
Click the maximize button twice. If you're already maximized, that will restore it to a normal window and then re-maximize it; if it's not already maximized, it will do the opposite. In either case, it should cause screen to recompute the window size.
I encountered the same problem today. Thank everyone for the heads-up. The final solution I found out is that to set the mintty term type to: vt220. There must be something not right about the "xterm". After that, everything is good.
I'm answering my own question here because, while #Keith Thompson's answer does resolve the symptom of the problem, it didn't keep the symptom from occurring. He did set me on the right path, which was to install the xterm package in cygwin-64. That appears to have resolved the issue.
I downgraded screen version to Screen version 4.02.01 (GNU) 28-Apr-14 and it worked.
I am wondering if there is a public api/framework where I can set the computer sleep value and the display sleep value in a cocoa application on mac os x? I am interested in making a utility application that will place an icon in the menu bar, allow the user to create different power option settings and what not.
I am not interested in using any private frameworks as I want to develop this application for the Mac App Store.
I always find myself changing the energy saver and screen saver values when i'm a home and when I wont be at home. Because I use Carbonite, I always leave my machine running. When I'm at home, I like the screen saver to come on after so many minutes, but when I away, like when I'm at work or a sleep at night, I prefer the screen saver to be off and the screen to sleep after one minute of inactivity. It would be nice to not have to go into system preferences all the time to do this. Any one else agree?
Thanks,
You can create a wrapper around the pmset utility, which allows you to change the power management settings on the command line, using either system() or (better) an NSTask.