I am running bluetoothctl v5.48 on SuSE LEAP 15.1.
The blue prompts [xyz] change from time to time.
For example [CHG] or [device name].
What is this telling me?
I have hunted (without success) for somthing more informative that a web page repeating the "help" command.
Related
This code:
use Term::ANSIColor;
print color("blink bold red"), "TEST\n";
print color("reset");
Has worked for eons on whatever linux console I have used it on. However, I when I try it on a Raspberry Pi console (not Xwindows) running Raspbian Stretch it simply colors the text red but does not blink. Anyone have any ideas as to how I can get this to work?
Attributes such as blink, italic, or bold may not work with the 256-color palette. -documentation
After experimenting I can conclude that the reason that perl ANSI color's blink feature does not work on a Raspberry PI is because the monitor is connected via HDMI. perl ANSI color does in fact blink on a Raspberry PI if one logs in remotely from a machine with a VGA monitor.
Update: Further testing concludes the blinking feature will NOT work by using a HDMI to VGA adapter to connect a VGA monitor to the raspberry PI -- so save yourself the money. The only way possible to get perl ANSIColor's blink feature to work on a PI is by sshing to the machine from a VGA displayed machine.
I'm running GNOME on Angstrom Linux on a Beagleboard, and have an issue when the device boots, i'm running the 2013-06-20 image from http://beagleboard.org/latest-images.
Power on, and the screen will display the Beagleboard logo, and continues to boot up. The screen goes black, but instead of loading onto the desktop, the screens (I've tried a few just to make sure) report no output from the device. If i move the mouse/press a key on the keyboard however it wakes up and displays the desktop.
Has anyone else experienced this? Is there a way to prevent this 'sleep mode' (I doubt that's what it is, its just the best phrase I can think of describe this problem) from happening and just to boot up & display the desktop?
Cheers.
This seems to have fixed the issue I was having, firstly I'd suggest updating any outdated packages by opening a terminal and typing
opkg update
this should only take ~1 minute, aftewards type
opkg upgrade
This can take anywhere from ~10minutes to ~6 hours maybe even more, so be patient, just leave the device alone until it has finished.
then open the following file
nano /etc/X11/xorg.conf
and add the following
Section "ServerFlags"
Option "BlankTime" "0"
Option "StandbyTime" "0"
Option "SuspendTime" "0"
Option "OffTime" "0"
EndSection
Section "Monitor"
Option "DPMS"
Identifier "Builtin Default Monitor"
EndSection
This should also disable any screensavers etc... which was also ideal for my requirements.
Reboot your device, and it should be good to go.
The X11 system bell does not work. I don't get any sound on xterm (e.g., echo \\007) nor when I call XBell(), for example, in the following program:
Display *display=XOpenDisplay(NULL);
XBell(display, 1000);
XFlush(display);
xset gives the correct settings for bell sounds, but this doesn't seem to have any effect. I do get a bell sound in konsole. It plays a sound file (bell.oga). If I could get X to play this sound that would be just fine.
I found out that the pulseaudio configuration has a line commented-out that is relevant to the bell sound (referring to x11-bell module). What pulseaudio is supposed to do here is to catch bell events and play the sound. I uncommented it and tweaked it a little and it still doesn't work, though now suddenly firefox makes bell sounds in certain situations which it didn't do before (which means that something did change).
Any idea how I can find out where the bell events get lost on the way?
I have KDE 4.3.4 running on CentOS release 6.5, Linux 2.6.32.
I am trying to close the Ubuntu onscreen keyboard named onboard with a command entered by that keyboard. What happens is if I type a kill command such as the following using the onscreen keyboard itself. . .
killall onboard
and then hit Enter again on the onscreen keyboard, I get continuous Enter hits on the terminal I was on. It's like I unplugged a physical keyboard and it keeps thinking I'm hitting the key I depressed as it was being unplugged.
I can't find any documentation online for how to do this any better so I thought I would ask here. I've tried the following sending the following kill signals which all have the same behavior: 1 (SIGHUP), 2 (SIGINT), 9 (SIGKILL), 15 (SIGTERM), and 24 (SIGXCPU).
Any ideas? I'm hoping I'm missing something obvious. . .
So I found the answer: https://bugs.launchpad.net/onboard/+bug/1032042
Once you have onboard 0.99 installed and running, you can execute the following two commands to show and hide the keyboard respectively without having to kill the process:
dbus-send --type=method_call --dest=org.onboard.Onboard /org/onboard/Onboard/Keyboard org.onboard.Onboard.Keyboard.Show
dbus-send --type=method_call --dest=org.onboard.Onboard /org/onboard/Onboard/Keyboard org.onboard.Onboard.Keyboard.Hide
This solved all my problems in a way better than just killing it.
I'm trying to set up a VM based on Ubuntu Minimal to test out working with the framebuffer/DirectFB. I want the VM to only display what I put on the framebuffer, while I'm controlling the VM over SSH. So ideally, it boots to a blank screen without a console.
I enabled the framebuffer device by adding video=vesafb and vga=0x305 to the kernel parameters. The framebuffer is working, because "cat /dev/urandom > /dev/fb0" (over ssh) fills the screen with noise.
However, the VM still shows console 1/tty1, and even after I fill the framebuffer with data, there is still a blinking cursor.
How do I turn off the framebuffer console?
Try to add console=/dev/null as a kernel parameter, it should help.