I am trying to get knowledge on alsa. When I saw it, it is automatically storing the previous states of the mixer controls and restoring them in the reboots. So I commented this process from the files /etc/init/alsa-restore.conf /etc/init/alsa-store.conf . After that I make one control to True and rebooted my system. After rebooting I checked the value of the control which is false now.
From where alsa get that control value as false after reboot.
There is no file /var/lib/alsa/asound.state because I removed it.
The initial state of mixer controls is determined either by the driver or by the device itself.
Furthermore, when asound.state does not yet exist, many distributions will call alsactl init.
If you want a mixer control to have a specific value, you must set this value somehow.
If you don't want to rely on asound.state, you could run your own script that sets the control with amixer.
To edit alsamixer settings in linux
use command:
$ alsamixer
just type alsamixer to open alsamixer in terminal
Related
I am running ubuntu 18.04, kernel 4.19.94-ti-r36, on a a beaglebone black. I am connected to ssh, and am trying to adjust the boot configuration of the GPIO pins. After boot, I am able to change and query individual GPIO configurations with the "config-pin" command, which is useful for experimentation. But I would like to change all the default GPIO configuration on boot, which this tool does not appear to do.
I found this tutorial on using a device overlay to achieve this here:
http://derekmolloy.ie/gpios-on-the-beaglebone-black-using-device-tree-overlays/
but I am missing the "bone_capemgr.8" directory. I googled this issue and was directed to this page, which says that device tree overlays are now deprecated, and to use u-boot overlays instead:
https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays.2C_which_got_loaded
I read through the article, and googled around, but I haven't found anything on how to actually use a u-boot overlay to change the configuration of the GPIO pins on boot.
Does anyone know how to do this, or know where I might find a good resource to this effect?
Thanks!
Edit: here are the steps I think I need to take, based on De Funct's answer:
install bb.org-overlays found here, https://github.com/beagleboard/bb.org-overlays, with:
sudo apt install bb-cape-overlays
create a .dts file with the correct configuration
compile .dts-->.dtbo file:
dtc -O dtb -o out_file.dtbo -b 0 -# in_file.dts (or something similar?)
adjust this line in /boot/uEnv.txt file to reference compiled dts
###Overide capes with eeprom
#uboot_overlay_addr0=/lib/firmware/.dtbo
something to do with boot images (?)
Questions:
what does searching "in the kernel" mean? how would I do this?
for the actual .dts file, I looked around and found this as a starting point:
https://github.com/derekmolloy/boneDeviceTree/blob/master/overlay/DM-GPIO-Test.dts My plan is to modify/extend lines 29-33 to change the boot configuration of all relevant pins. The second hex number is the pin mode I'm trying to change; that makes sense. The first hex number looks like it somehow corresponds to pin number, but I'm not sure how? for example, 0x078-->P9.12,0x184-->P9.24, etc.
when/where does making an image come into play? what about making two different partitions? I didn't follow that part
to use the uboot-overlays, which is a given for most concepts with GPIO pins on the BBB, one would have to install bb.org-overlays which are found here, https://github.com/beagleboard/bb.org-overlays, and to understand Device-Tree Specifications.
https://github.com/beagleboard/BeagleBoard-DeviceTrees will help you, too.
The Device Tree specification can be found here: https://www.devicetree.org/
In the kernel, you can search the docs. and kernel for specific, already-made device tree ideas and files.
Also, it is as simple as creating your dts file, compiling it, and putting it in the correct space on the BeagleBone Black in /boot/uEnv.txt.
For instance, if I had a specific .dtbo that I compiled from my .dts file(s), I would simply put it in the /boot/uEnv.txt file under this heading...
###Overide capes with eeprom
#uboot_overlay_addr0=/lib/firmware/<file0>.dtbo
http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays should explain the ideas I am listing.
Oh! Also, when creating your image, one would have to create the two partitions, one for booting and the other for the actual OS/filesystem.
Once this is completed, one would have to install the file uEnv.txt in the /boot dir. by simply making the file in a text editor, saving it, and placing it in the system before compilation via make menuconfig or whatever you are using to install the boot partition and OS partition.
If you need exact placements of the files in the kernel to search under for the .dts, .dtb, and .dtbo files, ask away. I have had complications with this before and lacking understanding, I have been a drift. Luckily, there is a long list of ideas but one needs to make them accessible in the correct order.
Also: https://www.digikey.com/eewiki/display/linuxonarm/BeagleBone+Black are some ideas on how to start the image factory of making things available for the BeagleBone Black.
Edit: here are the steps I think I need to take, based on De Funct's answer:
install bb.org-overlays found here, https://github.com/beagleboard/bb.org-overlays, with:
git clone https://github.com/beagleboard/bb.org-overlays
create a .dts file with the correct configuration
Your configuration of the .dts file works too...(supposedly as I have not seen it).
compile .dts-->.dtbo file:
dtc -O dtb -o out_file.dtbo -b 0 -# in_file.dts (or something similar?)
Not this idea. Although, compiling using the device-tree-compiler is an option, I say use their build script w/ their Makefile.
So, try ./install.sh
adjust this line in /boot/uEnv.txt file to reference compiled dts
###Overide capes with eeprom
uboot_overlay_addr0=/lib/firmware/your_newly_added_file.dtbo
...
Also and excuse me if this does not work, you can try with the BeagleBoard-DeviceTrees link I provided.
In that one, you would simply place the correct file, your .dts file, in the /src/arm/ directory, and go back to the BeagleBoard-DeviceTrees/ dir. to perform the make command.
It will perform all the necessary .dts to .dtb to .dtbo file operations.
This is the /boot/uEnv.txt file I have currently...
#Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0
uname_r=4.19.94-ti-r59
#uuid=
#dtb=
###U-Boot Overlays###
###Documentation: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays
###Master Enable
enable_uboot_overlays=1
###
###Overide capes with eeprom
uboot_overlay_addr0=/lib/firmware/BB-UART2-00A0.dtbo
#uboot_overlay_addr1=/lib/firmware/<file1>.dtbo
#uboot_overlay_addr2=/lib/firmware/<file2>.dtbo
#uboot_overlay_addr3=/lib/firmware/<file3>.dtbo
###
###Additional custom capes
#uboot_overlay_addr4=/lib/firmware/<file4>.dtbo
#uboot_overlay_addr5=/lib/firmware/<file5>.dtbo
#uboot_overlay_addr6=/lib/firmware/<file6>.dtbo
#uboot_overlay_addr7=/lib/firmware/<file7>.dtbo
###
###Custom Cape
#dtb_overlay=/lib/firmware/<file8>.dtbo
###
###Disable auto loading of virtual capes (emmc/video/wireless/adc)
#disable_uboot_overlay_emmc=1
#disable_uboot_overlay_video=1
#disable_uboot_overlay_audio=1
#disable_uboot_overlay_wireless=1
#disable_uboot_overlay_adc=1
###
###PRUSS OPTIONS
###pru_rproc (4.14.x-ti kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo
###pru_rproc (4.19.x-ti kernel)
uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo
###pru_uio (4.14.x-ti, 4.19.x-ti & mainline/bone kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo
###
See where the file states #dtb=? That is section where the .dtb needs to be located and uncommented by removing the hash symbol.
Also, under that particular section of the file, there are u_boot-overlay sections. You can now add your .dtbo files in those particular slots.
Working with Pure Data, trying to record audio output from a patch I've made, and am 1) unable to create a file within pure data to write to and 2) attempting to use the writesf~ object causes the program to freeze after about two to three seconds. I suspect the two things are related- perhaps the program is attempting to write data somewhere, somehow, but it's going in the wrong place or some such and causing the program to freeze?
I've uninstalled the latest Pure Data release (0.51-1) and installed an earlier stable release (0.5-2) and even tried an alternative called "purr data (latest release)" all with the exact same result on my windows 10 acer laptop: no file created, and program freezes after a few seconds.
I'm testing with this patch:
I first click on the message that reads "open rec.wav" then the start then the stop, and if I take longer than three or so seconds to click on "stop" the program freezes, otherwise nothing at all happens.
I have performed system wide search for the audio file, including the folder that the patch is in, all to no avail.
Any trouble shooting hints will be carefully attempted.
Are you sure you have write-permissions on the target directory?
If your example you use rec.wav which has no explicit target directory (and is just using the "current", so it's hard to tell from outside what this directory would be).
#max-n's answer suggests to use /tmp/foo.wav which is an illegal directory on Windows. Due to a known bug, using an illegal (or otherwise non-writable) path will lock up Pd.
If your "current" directory happens to be your system root (aka C:\), you might well lack the permissions to write there.
You could check by starting the Pd from the cmdline and see whether the terminal spits out any weird errors:
⊞ Win+R
type cmd and hit Enter
in the opening terminal type the full path to your Pd-executable, e.g.:
C:\Program Files\Pd\bin\pd + Enter
(ideally leave out the extension (that is: use .../pd rather than .../pd.exe)
If the problem is indeed a permission problem, you can simply work around it by specifying the full path of the output file (and make sure that it is in a writable directory).
The easiest way to do this is by using a file-selector to choose the output file:
[bang(
|
[savepanel]
|
[open $1(
|
[writesf~]
There might be a reason why the helpfile uses a [delay 1000] to schedule a stop message in a predefined time.
Would anyone know how to disable the virtual terminals in linux? I am using Yocto, Morty version on an i.MX6 processor. Even though our base distribution is Yocto, unfortunately we have diverged from building it with recipes, so this is more of a straight linux question than Yocto…
To give some detail as to my problem: It is for an embedded device that has an HDMI port - when I attach a terminal to the HDMI port it shows the Linux Penguin logo, a getty service and blanks out after 600 seconds. I just want to use the hdmi port as an output with nothing displayed on the output and I want it to stay on all the time.
I have found that the hdmi port maps to /dev/tty1 – when I type: echo “asdfasdf” > /dev/tty1 I see the characters output to the monitor.
Here are a few things I have tried to no avail – a lot of these are not needed if I can figure out how to disable it as a virtual terminal…
• I figured out how to disable the getty service but a cursor still blinks. I don’t even want a cursor to show
• I have tried to disable the display of the penguins by disabling the LOGO in the kernel config parameters - I commented anything with LOGO out:
CONFIG_LOGO=y
CONFIG_LOGO_LINUX_MONO=y
CONFIG_LOGO_LINUX_VGA16=y
CONFIG_LOGO_LINUX_CLUT224=y
To no avail. The logo still shows : .
• The fact that it blanks after 600 seconds is console blanking – I can see it set to 600 in the file: /sys/module/kernel/parameters/consoleblank. When I issue the command: echo -e '\033[9;0]'>/dev/tty1
It sets the console blanking to 0 and wakes the terminal. Being able to wake the console up is limited success but I would like to disable the virtual terminal altogether…
• I tried commenting out any virtual terminal defines in the config file to no avail:
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_VT_CONSOLE_SLEEP=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
Everything I have read suggests that /dev/tty1 is a virtual terminal or console. From what I read about the VT option, disabling the CONFIG_VT should do it:
VT — Virtual terminal Say yes here to get support for terminal devices
with display and keyboard devices. These are called "virtual" because
you can run several virtual terminals (also called virtual consoles)
on one physical terminal. You need at least one virtual terminal
device in order to make use of your keyboard and monitor. Therefore,
only people configuring an embedded system would want to say no here
in order to save some memory; the only way to log into such a system
is then via a serial or network connection. Virtual terminals are
useful because, for example, one virtual terminal can display system
messages and warnings, another one can be used for a text-mode user
session, and a third could run an X session, all in parallel.
Switching between virtual terminals is done with certain key
combinations, usually Alt-function key. If you are unsure, say yes, or
else you won't be able to do much with your Linux system.
But for some reason it doesn’t do anything!
• I found this thread; https://askubuntu.com/questions/357039/how-do-i-disable-virtual-consoles-tty1-6 among others, but none are much help since my distribution does not have any of the directories in the solutions offered in this thread or any others I have found. For instance I do not have a /etc/events.d nor do I have a /etc/default/console-setup file nor do I have a /etc/init directory… I imagine the reason for this is that my distribution uses systemd and the solutions are SysV based init maybe?
Disabling the logo or console blanking would not be necessary if I could just figure out how to disable that port as a terminal…
So does anyone have pointers or things I could try? I am relatively new (returning after 10 years - I worked with DNX 10 years ago v2.6 and it seems everything I knew about init is fairly obsolete lol) to linux so I am sure I am missing a lot…
Thanks,
- Chuck
I think I found the answer to my question. This is actually a frame buffer console documented here: Documentation/fb/fbcon.txt. From the documentation:
The framebuffer console (fbcon), as its name implies, is a text
console running on top of the framebuffer device. It has the
functionality of any standard text console driver, such as the VGA
console, with the added features that can be attributed to the
graphical nature of the framebuffer.
Commenting out the line
CONFIG_FRAMEBUFFER_CONSOLE=y
In the configuration file located in /arch/arm/configs will disable it.
Also this part of the documentation shows you how to disable it at runtime:
So, how do we unbind fbcon from the console? Part of the answer is in
Documentation/console/console.txt. To summarize:
Echo a value to the bind file that represents the framebuffer console
driver. So assuming vtcon1 represents fbcon, then:
echo 1 > sys/class/vtconsole/vtcon1/bind - attach framebuffer console
to
console layer echo 0 > sys/class/vtconsole/vtcon1/bind - detach framebuffer console from
console layer
When I issue the echo 0 command, the cursor stops blinking and starts blinking again when I issue the echo 1 command.
I think there is another way of doing it as well by modifying the Yocto build environment by putting the USE_VT="0" in the OpenEmbedded machine config file. The "USE_VT" variable is referenced by the sysvinit-inittab recipe. This answer was given to me from the Yocto Linux mailing list - but I have not tested it since we have diverged from Yocto...
I have a bluetooth remote that is paired with my linux box, when active, this remote is visible at /dev/input/event13.
I have a small C program that open this device and read directly from it, which works fine.
Now, my problem is that this remote goes to sleep after a few minutes of inactivity and /dev/input/event13 disappears. It reappears as soon as I press a key on my remote.
I put the output of udevadm here: https://gist.github.com/9fff2f0d7edef1050060.
I use the following code (small ruby ext I wrote), to read from the device: https://gist.github.com/b403d538eb6a8627e2bd.
I thought of writing an udev rule that would start my program when my remote is added and stop it when it is removed. I read the udev documentation, but I couldn't figure it out how to do it. I'm open for suggestion.
After some digging and a lot of frustration I did the following:
I put into /etc/udev/rules.d/99-rmote.rules
KERNEL=="event*", SUBSYSTEM=="input", ACTION=="add|remove", ATTRS{name}=="TiVo Keyboard Remote", RUN+="/home/kuon/handleConnect.rb"
And in handleConnect.rb I check the ACTION environment variable and I start/stop my daemon accordingly. Quite simple in the end and it works well.
Problem:
I have an extra set of top and bottom gnome-panels for a second monitor. When I undock my lenovo Thinkpad (T510), the extra top and bottom panels remain, so I have two on top and two on the bottom. I am currently running a RHEL6/Fedora (x86_64) gnome (2.28.2) instance with xmonad (0.9.1-6.1.el6) set as the window manager, using the xmonad extensions to work within gnome.
Tried:
I've used acpi and found a code for docking and undocking, but when I try to utilize a script I found in this blog post, it gets zero for the call to xrandr. The script works when called on its own from the terminal. I've tried calling a separate looping script in its own thread and it keeps getting zero for the value, long after the screen(s) update(s).
I have figured out how to have a script loop every X seconds and check for a file which is touched into existence in the event of the script getting a zero, then performing the necessary change, but I don't like that approach.
Question:
I'm hoping someone knows a place I can drop a call to the referenced script and have my panels come and go as I would expect without needing to initiate the script manually.
Thanks!
Update: I have added a bounty of 50 (max I can do) for an answer.
Ben
I guess one of the problems listed below occures (or both):
1) looks like your xrandr snippet doesn't return proper values because the $DISPLAY environment variable is not set correctly. Acpi handler script normally runs as a user which is not the user running your current X session. That way xrandr just does not know which $DISPLAY to access.
2) if $DISPLAY is set correctly, the acpid user might still not be able to access your running xsession. You might check whether the script will work over acpi handler, if you execute xhost + as the user who is currently runging the current xsession with $DISPLAY specified in your script. This will disable access control for X. You can reenable it with xhost - again.
Check it, I hope it helps or will at least point you in which direction to dig.