I have a ThinkPad X1 Yoga (2nd gen) and when running Ubuntu 17.04 I could change the brightness like this:
$ xrandr --output eDP-1 --brightness .7
Now, when I do that under 17.10 I get this:
warning: output eDP-1 not found; ignoring
xrandr: Need crtc to set gamma on.
When I hit brightness up and down buttons I see the numerical value in this file changing properly:
/sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1/intel_backlight/brightness
But xrandr reports a new label:
$ xrandr -q
Screen 0: minimum 320 x 200, current 2560 x 1440, maximum 8192 x 8192
XWAYLAND0 connected 2560x1440+0+0 (normal left inverted right x axis y axis) 310mm x 180mm
2560x1440 59.96*+
I've tried replacing eDP-1 with XWAYLAND0 but it returns 0 with no errors and nothing at all happens to the brightness.
$ xrandr --output XWAYLAND0 --brightness 0.5
$ echo $?
0
Would love some help on getting brightness settings working again. Right now it's stuck on full brightness all the time, which isn't great for the battery.
xrandr is made for X11 and won't work on Wayland. At least I'm not aware of any Wayland protocol for this yet (though one could easily be made).
There might be some gnome-shell (if that's the compositor you're using) tool for this, though, but I'm not too familiar with gnome.
Related
I've been able to record .h264 files without a problem, both using raspivid and through Python, but whatever I try, I can't convert them to a .mp4, .mkv or .avi file.
I've tried converting using MP4box (suggested in several places) and mkvmerge, but to no avail.
When I use MP4box (MP4box -add <source.h264> <dest.mp4>), I get :
AVC-H264 import - frame size 1920 x 1080 at 25.000 FPS
WARNING: NAL Unit type 0 not handled - adding5/100)
AVC Import results: 44 samples - Slices: 3 I 41 P 0 B - 0 SEI - 3 IDR
Saving video.mp4: 0.500 secs Interleaving
Then I try to play this file using VLC, it doesn't give an error, but shows garbled data.
To be clear, the camera works fine (shows perfect video using Python code and raspistill outputs a perfect jpg file). I tried a different camera as well.
An attempt with mkvmerge :
pi#raspberrypi:~/cam $ raspivid -o test.h264 -fps 30 -t 15000 -w 1920 -h 1080
pi#raspberrypi:~/cam $ mkvmerge --default-duration 0:30p -o video.mkv test.h264
mkvmerge v31.0.0 ('Dolores In A Shoestand') 32-bit
'test.h264': Using the demultiplexer for the format 'AVC/h.264'.
'test.h264' track 0: Using the output module for the format 'AVC/h.264 (unframed)'.
The file 'video.mkv' has been opened for writing.
Error: 'test.h264' track 0: mkvmerge encountered broken or unparsable data in this AVC/h.264 video track. Either your file is damaged (which mkvmerge cannot cope with yet) or this is a bug in mkvmerge itself. The error message was:
Success
pi#raspberrypi:~/cam $
This is on a Raspberry Pi 4.
A sample file can be found here : https://filebin.net/c40usz0crhgggadf
Created with : raspivid -t 30000 -w 640 -h 480 -fps 25 -b 1200000 -p 0,0,640,480 -o pivideo.h264
I'm going to respond to this myself. After doing an 'apt-get upgrade', the problem is gone.
If anyone wants to figure this out to find the root cause, this is what apt-get did :
The following packages will be upgraded:
bind9-host bluez-firmware firmware-atheros firmware-brcm80211 firmware-libertas firmware-misc-nonfree firmware-realtek libbind9-161 libdns-export1104 libdns1104 libgs9 libgs9-common libisc-export1100 libisc1100 libisccc161
libisccfg163 liblwres161 libraspberrypi-bin libraspberrypi-dev libraspberrypi-doc libraspberrypi0 pi-bluetooth raspberrypi-bootloader raspberrypi-kernel raspberrypi-kernel-headers raspi-config rpd-plym-splash
The following packages will be DOWNGRADED:
python3-pgzero
27 upgraded, 0 newly installed, 1 downgraded, 0 to remove and 0 not upgraded.
for studying Qemu I got the 'QEMU Eclipse' plugin, built the 'blinky' project from https://gnu-mcu-eclipse.github.io/tutorials/blinky-arm/ and when I let it run, it produces the following output:
xPack 64-bit QEMU v2.8.0-9 (qemu-system-gnuarmeclipse).
Board: 'STM32F4-Discovery' (ST Discovery kit for STM32F407/417 lines).
Board picture: '/home/hgiese/Work/qemu-arm-dev/linux-x64/install/qemu-arm/share/qemu/graphics/STM32F4-Discovery.jpg'.
Device file: '/home/hgiese/Work/qemu-arm-dev/linux-x64/install/qemu-arm/share/qemu/devices/STM32F40x-qemu.json'.
Device: 'STM32F407VG' (Cortex-M4 r0p0, MPU, 4 NVIC prio bits, 82 IRQs), Flash: 1024 kB, RAM: 128 kB.
Command line: 'blinky' (6 bytes).
...
and when I let it run everything was fine.
Now, when I called Qemu directly (outside of Eclipse) with the exact command line the output was this:
xPack 64-bit QEMU v2.8.0-9 (qemu-system-gnuarmeclipse).
Board: 'STM32F4-Discovery' (ST Discovery kit for STM32F407/417 lines).
Board picture: '/home/hgiese/Work/qemu-arm-dev/linux-x64/install/qemu-arm/share/qemu/graphics/STM32F4-Discovery.jpg'.
Device file: '/home/hgiese/Work/qemu-arm-dev/linux-x64/install/qemu-arm/share/qemu/devices/STM32F40x-qemu.json'.
Device: 'STM32F407VG' (Cortex-M4 r0p0, MPU, 4 NVIC prio bits, 82 IRQs), Flash: 1024 kB, RAM: 128 kB.
Command line: 'blinky' (6 bytes).
qemu-system-gnuarmeclipse: Guest image must be specified (using --image)
no matter how I specified 'blinky':
being in the Debug directory
calling it as blinky.elf
calling it with its complete path
It got even stranger: In an attempt to produce an error message from Qemu (which might tell me something) I replaced 'blinky' with 'xyz' (in the command line field of the 'Debugger' pane in the 'Debug Configuration' dialog) - and it still worked. The only difference being the line
Command line: 'xyz' (3 bytes).
in Qemu's output, which showed me that Qemu had received this dummy parameter - and it didn't make the slightest difference for it: it still had the correct image file.
How do I have to communicate the image file to Qemu (or 'How does Eclipse does its magic?')
Any insight will be greatly appreciated.
Helmut
Could anybody help me out to understand how to create virtual display for Raspberry Pi 3 B running Raspbian using xrandr?
I saw that it is possible to do this, for example, for Ubuntu and Linux Mint by executing these commands:
#!/bin/bash
xrandr --newmode "1920x1080_60.00" 173.00 1920 2048 2248 2576 1080 1083 1088 1120 -hsync +vsync
xrandr --addmode VIRTUAL1 1920x1080_60.00
sleep 2
xrandr --output VIRTUAL1 --mode 1920x1080_60.00 --left-of HDMI1 --primary
xinput map-to-output $(xinput | grep -v 'XTEST.*pointer' |grep 'slave.*pointer' | grep -o 'id=*[0-9]*[0-9]' | cut -d'=' -f2) HDMI1
But under raspberry this script is not able to find VIRTUAL1 output.
When I simply run xrandr I get the following result:
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 320 x 240, current 1360 x 768, maximum 1360 x 768
default connected 1360x768+0+0 0mm x 0mm
1360x768 60.00*
1024x768 60.00
800x600 60.00 56.00
640x480 60.00
680x384 60.00
512x384 60.00
400x300 60.00 56.00
320x240 60.00
1920x1080_60.00 (0x2af) 172.800MHz -HSync +VSync
h: width 1920 start 2040 end 2248 total 2576 skew 0 clock 67.08KHz
v: height 1080 start 1081 end 1084 total 1118 clock 60.00Hz
with no VIRTUAL1 and HDMI1 listed, only default. Can't figure out what steps should be taken for these outputs to appear in the given list?
Or if it is not possible then how can I create virtual display using other tools?
You wont be creating a virtual display for use with RPI. What you need to do is link your display to xrandr. This is done with the following code in terminal.
DISPLAY=:0 xrandr
Once you have done this it will be linked to xrandr and you'll be able to use it as if on Linux. However, you will need to do this on every boot or create a script that will run on boot and do this for you.
Also using xrand are will not resize your frame-buffer, this will need to be done as well.
I have been struggling to get VideoReader working on Ubuntu 17.04. If I run a simple program:
v = VideoReader('flame.avi')
I get the following:
Error using VideoReader/init (line 619)
Could not read file due to an unexpected error. Reason: Unable to initialize the video obtain properties
Error in VideoReader (line 172)
obj.init(fileName);
Now, I have done a little bit of digging, and most people say that this error comes from not having gstreamer0.10 installed.
See: https://www.mathworks.com/matlabcentral/answers/165584-cannot-read-video-matlab-2014b-linux
This one says that gstreamer1.0 is not sufficient to fix this problem: https://www.mathworks.com/matlabcentral/answers/255157-can-t-load-video-using-videoreader-in-matlab-r2015-on-ubuntu-15-04-could-not-read-file-due-to-an-un
The problem comes from trying to install gstreamer0.10. It doesn't appear to be working in Ubuntu 17.
This one talks about how gstreamer isn't working on Ubuntu 17: https://www.mathworks.com/matlabcentral/answers/294258-hello-i-have-a-problem-with-videoreader-on-matlab-r2016a-with-ubtuntu-lts16-04
I was wondering if anyone had any ideas on how to overcome this issue? Is there a different package that I could install that would fulfill the same requirements? I have tried installing matlab-support, and that hasn't helped either. Is there a different issue other than gstreamer0.10?
I would prefer not to re-install Ubuntu 16.04, but understand if that is the only way. But surely, someone has gotten MATLAB working on Ubuntu 17?
A colleague of mine found a link to a post that solved my problem https://www.mathworks.com/matlabcentral/answers/329796-issue-with-libstdc-so-6
Essentially, you need to redirect MATLAB and tell it to not use its default libstdc++6 file and use your Linux system's instead. I went with the solution at the bottom, and wrote an alias for my .bashrc file.
alias matlab='LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.22 /usr/local/bin/matlab -desktop'
After testing it out, I have confirmed it works.
I had the exact same problem and I was able to solve it by running
sudo apt install gstreamer1.0-plugins-*
on Ubuntu 20.04 with MATLAB R2018a
Moreover, forcing MATLAB to use the system libstdc++ in ways 1. and 2. did not solve the problem:
Write in ~/.bashrc
alias matlab='LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.22 /usr/local/bin/matlab -desktop'
closing the terminal, open again, run matlab and still did not work.
going to /usr/local/MATLAB/R2018a/sys/os/glnxa64 and adding .bak to all libstdc++ files (as a means of making them "invisible" to matlab and force it to look for them in the system) did not work either.
EDIT
This is working for at least one video, but still other videos give me the same error. So it is not a full solution
EDIT
One such video I could not open with matlab's video reader becomes accessible after converting it with this script (using opencv).
import cv2
import tqdm
cap = cv2.VideoCapture("output.avi")
vw = None
nframes = 100
# for fast test, change the for loop to
# while True:
# to convert the whole video
for _ in tqdm.tqdm(range(nframes)):
ret, frame = cap.read()
if not ret:
break
if vw is None:
vw = cv2.VideoWriter("output_safe.avi", cv2.VideoWriter_fourcc('M','J','P','G'), 10, (frame.shape[1], frame.shape[0]))
vw.write(frame)
cap.release()
if vw is None:
vw.release()
These were the properties of the original video as reported with ffmpeg -i output.avi
Input #0, avi, from 'output.avi':
Metadata:
encoder : Lavf58.64.100
Duration: 00:01:00.00, start: 0.000000, bitrate: 1822 kb/s
Stream #0:0: Video: mpeg4 (Simple Profile) (FMP4 / 0x34504D46), yuv420p, 2592x1944 [SAR 1:1 DAR 4:3], 1817 kb/s, 25 fps, 25 tbr, 25 tbn, 25 tbc
and these are the new properties
Input #0, avi, from 'output_safe.avi':
Metadata:
encoder : Lavf58.61.100
Duration: 00:00:10.00, start: 0.000000, bitrate: 7594 kb/s
Stream #0:0: Video: mjpeg (Baseline) (MJPG / 0x47504A4D), yuvj420p(pc, bt470bg/unknown/unknown), 2592x1944, 7650 kb/s, 10 fps, 10 tbr, 10 tbn, 10 tbc
I've just installed RASPBIAN 3.18 and next packages:
wget http://mirrordirector.raspbian.org/raspbian/pool/main/b/bluez/bluez_4.99- 2_armhf.deb
wget http://mirrordirector.raspbian.org/raspbian/pool/main/libc/libcap- ng/libcap-ng0_0.6.6-2_armhf.deb
wget http://mirrordirector.raspbian.org/raspbian/pool/main/r/radvd/radvd_1.8.5- 1_armhf.deb
wget -O kernel.zip http://www.nordicsemi.com/eng/nordic/download_resource/41602/5/28710770
unzip kernel.zip
sudo dpkg -i radvd_1.8.5-1_armhf.deb
sudo dpkg -i libcap-ng0_0.6.6-2_armhf.deb
sudo dpkg -i bluez_4.99-2_armhf.deb
sudo dpkg -i linux-image-3.17.4-release+_1_armhf.deb
sudo dpkg -i linux-headers-3.17.4-release+_1_armhf.deb
sudo nano /boot/config.txt
Add the following line:
kernel=vmlinuz-3.17.4-release+ to config.txt
save and exit
sudo reboot
and when I restart I got an screen more or less as the print screen attached. Any idea ?
One thing is sure: The rainbow screen means the GPU firmware is loaded, but there is a problem with the kernel image. Which one? Impossible to say from here. Perhaps not found or corrupt. Might be that the kernel you got from www.nordicsemi.com is broken. Might be you have a typo somewhere. But it can also be a faulty SD-card. Or a wrong power supply. According to Google:
In some cases (Stuck on the Rainbow Screen), freezing at this point has been fixed by adding "boot_delay=1" to the config.txt file.
If nothing helps, you probably have to go back to the default Raspian kernel. If you need a more recent kernel than in the default Raspian, you can switch to Raspian testing. The testing kernel should be a bit more recent... and definitely works for me.
This might also help you (https://www.raspberrypi.org/forums/viewtopic.php?t=58151)
Error ACT LED patterns
While booting the ACT LED should blink in an irregular pattern, indicating it is reading from the card. If it starts blinking in a regular (Morse code like) pattern then it is signaling an error.
When it blinks just once: possibly you have a Rpi from Micron. Take a good look at the processor if it says M with an orbit around it, then using the latest software ( after Sept 2013 ) will solve your problem. Also make sure you have a 4Gb SD card: a 2Gb doesn't work in this particular case.
Other patterns that might appear during a failed boot mean:
3 flashes: start.elf not found
4 flashes: start.elf not launch-able (corrupt)
7 flashes: kernel.img not found
8 flashes: SDRAM not recognized. You need newer bootcode.bin/start.elf firmware, or your SDRAM is damaged
Firmware before 20th October 2012 required loader.bin, and the meaning of the flashes was slightly different:
3 flashes: loader.bin not found
4 flashes: loader.bin not launch-able (corrupt)
5 flashes: start.elf not found
6 flashes: start.elf not launch-able
7 flashes: kernel.img not found