I've been working on a script that will run on startup but I am running into a problem. The script is meant to slow mouse acceleration because I use a gaming mouse and it's always too fast.
When I use xinput --list I get this output (out of many other lines):
SteelSeries Sensei Raw Gaming Mouse id=10 [slave pointer (2)]
When I open terminal and run this command, everything runs fine and my sensitivity is changed:
xinput --set-prop 10 "Device Accel Constant Deceleration" 2
However, when I put the above string in a shell.sh with 'eval' in the beginning, it prompts me the following error:
property 'Device' doesn't exist, you need to specify its type and
format
What am I doing wrong?
You don't need eval; put the command exactly as you used it from the terminal in your script.
The problem is that eval essentially reparses the string it receives, which results from joining the arguments arguments with whitespace. Your eval command is equivalent to
xinput --set-prop 10 Device Accel Constant Deceleration 2
You could use eval if you quoted the entire string:
eval 'xinput --set-prop 10 "Device Accel Constant Deceleration" 2'
but there is no reason to do so; just use
xinput --set-prop 10 "Device Accel Constant Deceleration" 2
As said on other posts, you don't need to use eval. I would also add something else: you should use the name of the device, rather than the id number, because the id number can change if you add things to your computer (or for other more obscure reasons, too). I would recommend this:
xinput --set-prop "SteelSeries Sensei Raw Gaming Mouse" "Device Accel Constant Deceleration" 2
Related
I'm using a 14 inch M1 Pro Macbook Pro, running Mac OS Monterey 12.6.
I'm making an OpenCV and Mediapipe based Computer Vision Project that allows me to use hand detection to control my Mac's volume. The code detects the distance between the tips of my index finger and thumb using the webcam, and changes the volume based on that. I've been trying to use osascript to set the volume:
osascript.osascript("set volume output volume 0")
It works, but only for hard coded values like 0, 5 and 10. How do I pass a variable value N to osascript:
osascript.osascript("set volume output volume N")
If I could pass that variable value, then I could actually vary the volume instead of having it set at either 0, 5 or 10. The documentation hasn't been very helpful, anybody have any ideas or alternatives instead of osascript?
I've tried applescript but couldn't figure it out.
I'm guessing you are actually using Python, though you don't mention it in the question or in your tags.
If so, you can use an "f-string" like this - note the f at the start:
N = 7
osascript.osascript(f"set volume output volume {N}")
Use command
osascript -e "set Volume 10"
or use python library driver_controler https://github.com/Alexandro1112/driver-controller
I'm using Asus Tinker board and trying to use GPIO to control leds.
I'm very limmeted in what I can install so I'm using shell commends to do this.
like this:
echo 223 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio223/direction
echo 1 > /sys/class/gpio/gpio223/value
It's working fine but what I'm struggle to find is how can I proferm fade in/out (Breathing effect)
and I'm must stick to shell commands. so no Python or C
you need to implement PWM. In short: switching LED on and off very quickly and changing proportion of time when LED is on and off.
You can probably reach desired Breathing effect, but it's very CPU consuming. There are packages like gpio using hw timers, but installation is needed.
I wrote an FMX (FireMonkey) application and I want to change (increase / decrease) and mute / unmute the master volume output in OS X. Either in Delphi or C++Builder. Alternatively I would do it by simulating key presses of the specific keys of the keyboard.
For Windows, it is fairly easily by simulating key presses with SendInput() or even easier with keybd_event().
This is how it works on windows for me:
// vkVolumeUp / vkVolumeDown / vkVolumeMute
// VK_VOLUME_UP / VK_VOLUME_DOWN / VK_VOLUME_MUTE
keybd_event(vkVolumeUp, 1, 0, 0);
keybd_event(vkVolumeUp, 1, KEYEVENTF_KEYUP, 0);
But I can't manage to compile it for OS X, since the IDE tells me that it doesn't know this functions. A direct way to change the volume would be even better if it is possible.
This is probably a long-winded, inefficient way of doing it, but you can mute the volume from the Terminal like this:
osascript -e 'set volume with output muted'
and increase it by 20 notches like this
osascript -e 'set volume output volume ((output volume of (get volume settings)) + 20)'
I presume you could use the system() command to execute those till someone tells you a better way.
Currently I'm trying to check the booting time of an Tixi board using systemd on a 2.6.39 linux kernel. To do so I created a service file that calls a bash script which sets and uses a gpio. The problem is that my systems is not allowing me to change the value of the gpio. I can sucessfully export it, change its direction, but NOT the value. I have connected an oscilloscope to check if the value had changed in the hardware but not updated in the file as suggested in some forums, but it was the same: the value just doesn't change!
I should also point out that the same script is working if I use system V, with exactly the same coonfiguration for the kernel, busybox and filesystem.
It is very ironic because I'm already the root of the systems, nevertheless even changing the permissions of the file, would not allow me to change its value. There is also no feedback from the kernel saying that the operation was not possible, but rather it looks as if it was possible but when I check the value, it was the same as before.
I also tried to run that in the Raspbian with a 3.12 (which I changed to systemd) and it was in fact possible to do it, just in the normal way from userspace.
I would appreciate if you have any idea oh what might be the problem since I already run out of ideas.
Thanks
PS: This is the code that should work on the bash line:
echo 0 > /sys/class/gpio/gpio104/value
more /sys/class/gpio/gpio104/value
// I get 1 not 0 as I requested
Nevertheless the same lines of code in the same board work if I use systemV but not if I use systemd
Probably cause by the lack of udev in your new setup which change the permission for those gpio in /sys/class. You might want to just put back udev to see if it fixes your problem.
I don't know your image setting, but each gpio pins needs to be exported prior to usage. Are you doing it or it's done automatically? If you have omap mux kernel switch, you do something like :
echo 0x104 > /sys/kernel/debug/omap_mux/cam_d5 (set mode 4 as stipulate in TI Sitara TRM)
echo 104 > /sys/class/gpio/export (export the pin)
echo out > /sys/class/gpio/gpio104/direction (set the pin as output)
Also do a dmesg | grep gpio and see if there's any initializing problem with the gpio mux.
Actually I've faced an issue similar to your's , ie was not able to change the value of set of gpio pin manually
Finally the result obtained was even though the name of that pin is gpio it can only be used for input only (DM3730 gpiO_114 and gpio_115).
So please refer to the datasheet and confirm it can be used for I/O operations..
When I type any key, normally, it is immediately echoed back to the std output i.e.my screen.
If I have to enter a password, that says that it will not echo back, I cannot see the keys that I type.
How does this work.
Does each key press go to the kernel immediately(without me pressing ENTER), and then the kernel decides to echo them or not?
Like , I press 'A', it goes to the kernel; kernel echoes it; I get it on my screen. Now I hit 'B'...same sequence again...; Now I have 'AB' on my screen (my command) and hit ENTER; My command goes to the kernel and is finally executed.
Is there any other explanation? What happens in the background during the key presses?
The terminal driver in the kernel can be put in several modes (there are actually many more flags than this, and these days "cbreak" is actually the opposite of a different flag, so this is simplified).
The "cbreak" mode means that the process that is attempting to read from the terminal will receive keyboard input as soon as it is available. When cbreak mode is off, the data is stored by the kernel in a buffer until enter is pressed, and certain keys like backspace are handled by the kernel (when you press backspace, it removes the character from the buffer and - if echo mode is on - writes "backspace-space-backspace" to the terminal to overwrite the character with a blank space).
Echo mode means that whenever the user presses a key, the kernel will immediately echo it back to the screen. When it is off, nothing will be echoed to the screen, and the program will need to write it to the terminal if it wants you to see it.
There are several typical situations:
In programs that do advanced input handling (like most shells, or something like a full screen program), cbreak is on and echo is off; the program will write the character to the terminal itself if it is not part of a special key escape sequence.
In most situations [the default with a simple program that reads stdin and writes stdout], echo is on and cbreak is off. When you type, it behaves as I described above, all of this is handled by the kernel until you hit enter and it sends it to the application. Input editing is limited to backspace [and ctrl-u, ctrl-w], trying to use the arrow keys will just put escape sequences like ^[[D in the input line.
When reading a password, echo is off and cbreak is off. Input works just like the default case, except the kernel does not copy input to the screen.
The program that is running tells the kernel what mode to have it in with the termios functions. You can use the stty command to do the same in a shell environment, but be aware that this may interfere with the shell's own input handling or with what programs you run expect the default state to be.
Your keyboard generates electrical signals that are eventually interpreted as keycodes that correspond to letters - 'A', 'B', function keys F1, F2 etc. This all happen in the keyboard driver that is handled by the kernel. That keyboard driver has a buffer to receive all the keypresses from the keyboard and sends that to the kernel that in turn direct them to processes that is currently having the focus. What to do with the sequence of keys are totally decided by the individual application, such as whether to display the keys or not.
echo program is part of coreutils. You can download its sources here. Look at src/echo.c it's quite small. You can see that echo uses fputc or putchar calls. Those calls deal with standard stream called stdout. The architecture of standard streams is quite complicated and it's beyond of this post. You can found it using for example google.