I want to map the pactl volume control to:
$mod+(equal sign) to increase volume and
$mod+(minus sign) to decrease volume
But sway doens't take $mod+=, it writes: Unknown key or button '=' (the same is with the minus sign)
You can bindsym equal using bindsym $mod+equal and minus using bindsym $mod+minus
you can then increase/decrease the volume by 5% with pactl by:
bindsym $mod+equal exec --no-startup-id pactl set-sink-volume #DEFAULT_SINK# +5%
bindsym $mod+minus exec --no-startup-id pactl set-sink-volume #DEFAULT_SINK# -5%
For other keys, you can find the key symbol name by installing:
xev if running i3
wev if running sway
Running either of these programs from the terminal will open up a new window, and any events captured by that window (e.g. mouse moves, key presses etc.) will be printed in the terminal.
For example, I have sway installed. If I run wev and press the equal sign key I get:
[14: wl_keyboard] key: serial: 31683; time: 272340704; key: 21; state: 1 (pressed)
sym: equal (61), utf8: '='
where the key symbol is given by the sym field.
when running xev:
KeyPress event, serial 34, synthetic NO, window 0x600001,
root 0x2a0, subw 0x0, time 272462577, (372,40), root:(1179,512),
state 0x0, keycode 21 (keysym 0x3d, equal), same_screen YES,
XLookupString gives 1 bytes: (3d) "="
XmbLookupString gives 1 bytes: (3d) "="
XFilterEvent returns: False
where the symbol is given by the second value in the keysym field.
Related
I am trying to make sense of the following presentation, see page 27:
Could someone please describe the command line tools available in libjxl that can help me work with existing palettes ?
I tried a naive:
% convert -size 512x512 -depth 8 xc:white PNG8:white8.png
% convert -size 512x512 -depth 8 xc:white PNG24:white24.png
which gives me the exected:
% file white8.png white24.png
white8.png: PNG image data, 512 x 512, 8-bit colormap, non-interlaced
white24.png: PNG image data, 512 x 512, 8-bit/color RGB, non-interlaced
But then:
% cjxl -d 0 white8.png white8.jxl
% cjxl -d 0 white24.png white24.jxl
Gives:
% md5sum white8.jxl white24.jxl
68c88befec21604eab33f5e691a2a667 white8.jxl
68c88befec21604eab33f5e691a2a667 white24.jxl
where
% jxlinfo white8.jxl
dimensions: 512x512
have_container: 0
uses_original_profile: 1
bits_per_sample: 8
have_preview: 0
have_animation: 0
intrinsic xsize: 512
intrinsic ysize: 512
orientation: 1 (Normal)
num_color_channels: 3
num_extra_channels: 0
color profile:
format: JPEG XL encoded color profile
color_space: 0 (RGB color)
white_point: 1 (D65)
primaries: 1 (sRGB)
transfer_function: gamma: 0.454550
rendering_intent: 0 (Perceptual)
frame:
still frame, unnamed
I also tried:
% cjxl -d 0 --palette=1024 white24.png palette.jxl
which also gives:
% md5sum palette.jxl
68c88befec21604eab33f5e691a2a667 palette.jxl
The libjxl encoder either takes a JPEG bitstream as input (for the special case of lossless JPEG recompression), or pixels. It does not make any difference if those pixels are given via a PPM file, a PNG8 file, a PNG24 file, an RGB memory buffer, or any other way, if the pixels are the same, the result will be the same.
In your example, you have an image that is just solid white, so it will be encoded the same way regardless of how you pass it to cjxl.
Now if those pixels happen to use only few colors, as will be the case for PNG8 since there can be at most 256 colors in that case, the encoder (at a default effort setting) will detect this and use the jxl Palette transform to represent the image more compactly. In jxl, palettes can have arbitrary sizes, there is no limit to 256 colors. The --palette option in cjxl can be used to set the maximum number of colors for which it will still use the Palette transform — if the input image has more colors than that, it will not use Palette.
The use of Palette is considered an internal encoding tool in jxl, not part of the externally exposed image metadata. It can be used by the encoder to effectively recompress PNG8 files, but by no means will it necessarily always use that encoding tool when the input is PNG8, and it might also use Palette when the input has more than 256 colors. The Palette transform of jxl is quite versatile, it can also be applied to individual channels, to more or less than 3 channels, and palette entries can be not only specific colors but also so-called "delta palette entries" which are not a color but signed pixel values that get added to the predicted pixel value.
As explained by Jon Sneyers just above the palette is an internal encoding tool. I was confused by this, as I could not see any difference in the output of the jxlinfo command line.
So I ran the following experience on my side to convince myself:
$ cjxl -d 0 --palette=257 palette.png palette.257.jxl
$ cjxl -d 0 --palette=256 palette.png palette.256.jxl
$ cjxl -d 0 --palette=255 palette.png palette.255.jxl
Lead to:
% md5sum palette.*.jxl
e925521cbb976dce2646354ea3deee3b palette.255.jxl
8d241b94d67aeb2706a1aad7aed55cc7 palette.256.jxl
8d241b94d67aeb2706a1aad7aed55cc7 palette.257.jxl
Where:
% du -sb palette.*.jxl
89616 palette.255.jxl
45627 palette.256.jxl
45627 palette.257.jxl
In all case jxlinfo reveals:
% jxlinfo palette.255.jxl
dimensions: 256x256
have_container: 0
uses_original_profile: 1
bits_per_sample: 8
have_preview: 0
have_animation: 0
intrinsic xsize: 256
intrinsic ysize: 256
orientation: 1 (Normal)
num_color_channels: 3
num_extra_channels: 0
color profile:
format: JPEG XL encoded color profile
color_space: 0 (RGB color)
white_point: 1 (D65)
primaries: 1 (sRGB)
transfer_function: 13 (sRGB)
rendering_intent: 0 (Perceptual)
frame:
still frame, unnamed
With:
% pnginfo palette.png
palette.png...
Image Width: 256 Image Length: 256
Bitdepth (Bits/Sample): 8
Channels (Samples/Pixel): 1
Pixel depth (Pixel Depth): 8
Colour Type (Photometric Interpretation): PALETTED COLOUR (0 colours, 0 transparent)
Image filter: Single row per byte filter
Interlacing: No interlacing
Compression Scheme: Deflate method 8, 32k window
Resolution: 0, 0 (unit unknown)
FillOrder: msb-to-lsb
Byte Order: Network (Big Endian)
Number of text strings: 0
I'm trying to get a program to automatically crop a screenshot of the display to the correct size of the visible window.
Using this command to get the size and the position of the window:
$ xdotool getwindowfocus getwindowgeometry
Window 104857603
Position: 0,81 (screen: 0)
Geometry: 1920x1027
Using this command to get the display geometry:
$ xdotool getdisplaygeometry
1920 1080
It would be intuitive to think that the first value of the window's position plus the first value of the window's geometry would be equal to the first value of the display's geometry, and in this case it does (0 + 1920 = 1920). However when looking at the second output value 81 + 1027 > 1080. Why does that happen?
I'm trying to get the XY coordinates of a moving sprite in SmileBASIC, and I can't figure it out. I have the single variable returned from SPCHK, but when I print it, I get a single number '4' constantly as the sprite moves. How do I get each bit?
From the documentation:
Return Values for SPCHK
|b00| XY-coordinates (1), #CHKXY
|b01| Z-coordinates (2), #CHKZ
|b02| UV-coordinates (4), #CHKUV
|b03| Definition number (8), #CHKI
|b04| Rotation (16), #CHKR
|b05| Magnification XY (32), #CHKS
|b06| Display color (64), #CHKC
|b07| Variable (128), #CHKV
For each bit, a target is assigned (If 0 is assigned for all bits, animation is being stopped)
SPCHK only tells you which properties are currently being animated, not their values.
To get the actual position, you can use SPOFS id OUT x,y
Example:
SPSET 0,17
SPANIM 0,"XY",-10,100,100
WAIT 5
SPOFS 0 OUT X,Y
?X,Y 'should be 50,50
Is it possible to draw sinus function on the interval: [-2*pi, 2*pi] in the following way:
when I press right arrow on the keyboard to produce sinus function on the interval: [-2*pi, -pi]
when I press again to plot sinus function on the interval [-pi, 0]
....
Is it possible?
thanks!
To plot something when hitting a key, you must use the bind command, like
clear
bind Left 'plot sin(x)'
The clear opens an empty plot windows, which you must then give the focus, and then hit the arrow-left key to plot a sine.
Now you can put more logic into the command which is called in bind:
clear
i = 0
left_lim(n) = (i%2 ? -pi : -2*pi)
right_lim(n) = (i%2 ? 0 : -pi)
bind Left 'plot [-2*pi:2*pi][-1:1] (x < left_lim(i) || x > right_lim(i)) ? 1/0 : sin(x); i = i+1'
This draw the sine on the interval [-2*pi:-pi] at every odd time you press the key, and on the interval [-pi:0] at every even time you press it. The total xrange is always [-2*pi:2*pi] and the yrange is [-1:1].
Depending on your overall logic (what should happen if you hit the key a third time?) you must adapt this script a bit.
in the program for BLE112 I measure RSSI and then turn ON the LEDs. I have written a program for this purposes. I get RSSI and if the value is more then -70 dBm I turn on the LEDs in P_03 and P_04, and if the value is less then -70 dBm the LEDs are OFF.
But there is a problem: when I flash my module all is OK - the LEDs are OFF, but when I connect my phone with BLE112 the LEDs turn on and that's all! They don't respond to the statements of RSSI.
I can't find out any information about this problem, so I decide to ask you about this problem. I attach my project.
And this is part of code where I get RSSI and set to high PINs:
event hardware_soft_timer(handle)
if ( connected )
call connection_get_rssi(active_connection)(ret_connection, ret_rssi)
if ( ret_rssi > -80 )
call hardware_io_port_write(0, $18, $18)
else
call hardware_io_port_write(0, $18, 00)
end if
end if
"The "int8" data type is a signed (two's complement) 8-bit integer, which means that practically speaking, 0-127 represent those actual values, and 128 to 255 represent -128 to -1, respectively. Since RSSI values are always negative on the BLE, that means that the mathematical integer representation of -50, for example, will actually be 205." - Jeff Rowberg.
Do the following:
#Get RSSI value of connection
call connection_get_rssi(connection_handle)(connection_handle,rssi)
#Convert ASCII into integer
rssi = $100 - rssi
#if device is within range...
if rssi >= 80 then...
Oh..$100 is 256 in hex. You can simply use 256 will still work.