Otto K

@SMGJohn
di-camera-app is leaking (not freeing after use properly) a small amount of RAM every frame it processes. Normally this is not an issue since it does not exhaust the available RAM in 30 minutes, but with time restriction lifted you hit it at ~75min. There are two options to fix this - find a memory leak and fix it in di-camera-app binary (hard) and this possible quick hack if you (or somebody else) is willing to try - create and enable swap file and use it (leaked memory is no actually used and can be safely moved to swap). For some reason swap file on SD card is not working (swap partition might, but it's too much work for an average person), but there is a writeable partition in camera already with ~2GB free, mounted on /opt/usr, so this might help:
First to see hwo things look before (all commands from telnet session):
[root@drime5 ~]£ free
             total       used       free     shared    buffers     cached
Mem:        511580     499896      11684          0       5260      70556
-/+ buffers/cache:     424080      87500
Swap:            0          0          0
[root@drime5 ~]£ df -h /opt/usr
Filesystem            Size  Used Avail Use% Mounted on
/dev/mmcblk0p14       2.3G  105M  2.1G   5% /opt/usr
OK, so we have no swap and have plenty of free disk space on /opt/usr, let's create some swap:
[root@drime5 ~]£ dd if=/dev/zero of=/opt/usr/swap bs=1M count=512
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 42.882 s, 12.5 MB/s
[root@drime5 ~]£ mkswap /opt/usr/swap
Setting up swapspace version 1, size = 524284 KiB
no label, UUID=63995c82-cf71-43c6-ae32-34e520e7e280
Ouch, internal storage is not very fast... Let's turn it on:
[root@drime5 ~]£ swapon /opt/usr/swap
[root@drime5 ~]£ free
             total       used       free     shared    buffers     cached
Mem:        511580     506540       5040          0       4404      82108
-/+ buffers/cache:     420028      91552
Swap:       524284          0     524284
[root@drime5 ~]£ df -h /opt/usr
Filesystem            Size  Used Avail Use% Mounted on
/dev/mmcblk0p14       2.3G  617M  1.6G  29% /opt/usr
Yup, it works
You have to do everything before swapon only once, after that (and after every reboot) you only have to re-enable the swap with swapon /opt/usr/swap
I hope sombody with enough free time tests this, I have a good feeling.

@SMGJohn
di-camera-app is leaking (not freeing after use properly) a small amount of RAM every frame it processes. Normally this is not an issue since it does not exhaust the available RAM in 30 minutes, but with time restriction lifted you hit it at ~75min. There are two options to fix this - find a memory leak and fix it in di-camera-app binary (hard) and this possible quick hack if you (or somebody else) is willing to try - create and enable swap file and use it (leaked memory is no actually used and can be safely moved to swap). For some reason swap file on SD card is not working (swap partition might, but it's too much work for an average person), but there is a writeable partition in camera already with ~2GB free, mounted on /opt/usr, so this might help:
First to see hwo things look before (all commands from telnet session):
[root@drime5 ~]£ free
             total       used       free     shared    buffers     cached
Mem:        511580     499896      11684          0       5260      70556
-/+ buffers/cache:     424080      87500
Swap:            0          0          0
[root@drime5 ~]£ df -h /opt/usr
Filesystem            Size  Used Avail Use% Mounted on
/dev/mmcblk0p14       2.3G  105M  2.1G   5% /opt/usr
OK, so we have no swap and have plenty of free disk space on /opt/usr, let's create some swap:
[root@drime5 ~]£ dd if=/dev/zero of=/opt/usr/swap bs=1M count=512
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 42.882 s, 12.5 MB/s
[root@drime5 ~]£ mkswap /opt/usr/swap
Setting up swapspace version 1, size = 524284 KiB
no label, UUID=63995c82-cf71-43c6-ae32-34e520e7e280
Ouch, internal storage is not very fast... Let's turn it on:
[root@drime5 ~]£ swapon /opt/usr/swap
[root@drime5 ~]£ free
             total       used       free     shared    buffers     cached
Mem:        511580     506540       5040          0       4404      82108
-/+ buffers/cache:     420028      91552
Swap:       524284          0     524284
[root@drime5 ~]£ df -h /opt/usr
Filesystem            Size  Used Avail Use% Mounted on
/dev/mmcblk0p14       2.3G  617M  1.6G  29% /opt/usr
Yup, it works
You have to do everything before swapon only once, after that (and after every reboot) you only have to re-enable the swap with swapon /opt/usr/swap
I hope sombody with enough free time tests this, I have a good feeling.

http://***URL removed***/forums/post/57456860
:-)

http://***URL removed***/forums/thread/3980221#forum-post-57456639
:-)

@raj90 @ricardo_sousa11 you can kinda  already do that by putting settings in EV_RIGHT.sh and similar files and using keyscan utility documented in github repo. 

Simple "hack" to enable silent shooting in single mode (not CH/CN):
[root@drime5 ~]£ st cap capdtm getusr 117
UserData is ADJUSTSHUTTERTYPE_MECHA (0x750000)
[root@drime5 ~]£ st cap capdtm setusr 117 0x00750001
UserData is set
[root@drime5 ~]£ st cap capdtm getusr 117
UserData is ADJUSTSHUTTERTYPE_ROLLING (0x750001)
ROLLING is full electronic shutter
Now, why Samsung did not enable this in the menu I have no idea... It's fully working in full resolution JPEGs and SRW files.
I have not time to test whether image quality suffers, but it looks OK to me
Could someone check if it works with NX1 as well?
Cheers and have fun,
Otto

Simple "hack" to enable silent shooting in single mode (not CH/CN):
[root@drime5 ~]£ st cap capdtm getusr 117
UserData is ADJUSTSHUTTERTYPE_MECHA (0x750000)
[root@drime5 ~]£ st cap capdtm setusr 117 0x00750001
UserData is set
[root@drime5 ~]£ st cap capdtm getusr 117
UserData is ADJUSTSHUTTERTYPE_ROLLING (0x750001)
ROLLING is full electronic shutter
Now, why Samsung did not enable this in the menu I have no idea... It's fully working in full resolution JPEGs and SRW files.
I have not time to test whether image quality suffers, but it looks OK to me
Could someone check if it works with NX1 as well?
Cheers and have fun,
Otto

Simple "hack" to enable silent shooting in single mode (not CH/CN):
[root@drime5 ~]£ st cap capdtm getusr 117
UserData is ADJUSTSHUTTERTYPE_MECHA (0x750000)
[root@drime5 ~]£ st cap capdtm setusr 117 0x00750001
UserData is set
[root@drime5 ~]£ st cap capdtm getusr 117
UserData is ADJUSTSHUTTERTYPE_ROLLING (0x750001)
ROLLING is full electronic shutter
Now, why Samsung did not enable this in the menu I have no idea... It's fully working in full resolution JPEGs and SRW files.
I have not time to test whether image quality suffers, but it looks OK to me
Could someone check if it works with NX1 as well?
Cheers and have fun,
Otto

Simple "hack" to enable silent shooting in single mode (not CH/CN):
[root@drime5 ~]£ st cap capdtm getusr 117
UserData is ADJUSTSHUTTERTYPE_MECHA (0x750000)
[root@drime5 ~]£ st cap capdtm setusr 117 0x00750001
UserData is set
[root@drime5 ~]£ st cap capdtm getusr 117
UserData is ADJUSTSHUTTERTYPE_ROLLING (0x750001)
ROLLING is full electronic shutter
Now, why Samsung did not enable this in the menu I have no idea... It's fully working in full resolution JPEGs and SRW files.
I have not time to test whether image quality suffers, but it looks OK to me
Could someone check if it works with NX1 as well?
Cheers and have fun,
Otto

Simple "hack" to enable silent shooting in single mode (not CH/CN):
[root@drime5 ~]£ st cap capdtm getusr 117
UserData is ADJUSTSHUTTERTYPE_MECHA (0x750000)
[root@drime5 ~]£ st cap capdtm setusr 117 0x00750001
UserData is set
[root@drime5 ~]£ st cap capdtm getusr 117
UserData is ADJUSTSHUTTERTYPE_ROLLING (0x750001)
ROLLING is full electronic shutter
Now, why Samsung did not enable this in the menu I have no idea... It's fully working in full resolution JPEGs and SRW files.
I have not time to test whether image quality suffers, but it looks OK to me
Could someone check if it works with NX1 as well?
Cheers and have fun,
Otto

Simple "hack" to enable silent shooting in single mode (not CH/CN):
[root@drime5 ~]£ st cap capdtm getusr 117
UserData is ADJUSTSHUTTERTYPE_MECHA (0x750000)
[root@drime5 ~]£ st cap capdtm setusr 117 0x00750001
UserData is set
[root@drime5 ~]£ st cap capdtm getusr 117
UserData is ADJUSTSHUTTERTYPE_ROLLING (0x750001)
ROLLING is full electronic shutter
Now, why Samsung did not enable this in the menu I have no idea... It's fully working in full resolution JPEGs and SRW files.
I have not time to test whether image quality suffers, but it looks OK to me
Could someone check if it works with NX1 as well?
Cheers and have fun,
Otto

Simple "hack" to enable silent shooting in single mode (not CH/CN):
[root@drime5 ~]£ st cap capdtm getusr 117
UserData is ADJUSTSHUTTERTYPE_MECHA (0x750000)
[root@drime5 ~]£ st cap capdtm setusr 117 0x00750001
UserData is set
[root@drime5 ~]£ st cap capdtm getusr 117
UserData is ADJUSTSHUTTERTYPE_ROLLING (0x750001)
ROLLING is full electronic shutter
Now, why Samsung did not enable this in the menu I have no idea... It's fully working in full resolution JPEGs and SRW files.
I have not time to test whether image quality suffers, but it looks OK to me
Could someone check if it works with NX1 as well?
Cheers and have fun,
Otto

Here you go
http://***URL removed***/forums/thread/3979382#forum-post-57446956

Here you go
http://***URL removed***/forums/thread/3979382#forum-post-57446956

Here you go
http://***URL removed***/forums/thread/3979382#forum-post-57446956

@sandro there are plenty of tutorials on https://github.com/ottokiksmaler/nx500 including the archive you should unpack to SD card for telnet, etc. 

Ok, few short notes. 
First of all, there are two operating systems running, tizen and t-kernel based real time OS. What we see and can access is just a nice front end that issues messages to RTOS that actually does all the hard work. If some function is not implemented in it it's unfeasible for us. 
Regarding GUI - I'm working on it now and it's the most hostile toolkit I have ever worked with - EFL. Android is walk in the park compared to this hell.
As you can explicitly set readout to 120fps it either works slower (why?) or faster (240fps declared in the same NX1 launch event that also declared CGRA). 
Cpu cores are most likely based on 1600MHz A9. 

Ok, few short notes. 
First of all, there are two operating systems running, tizen and t-kernel based real time OS. What we see and can access is just a nice front end that issues messages to RTOS that actually does all the hard work. If some function is not implemented in it it's unfeasible for us. 
Regarding GUI - I'm working on it now and it's the most hostile toolkit I have ever worked with - EFL. Android is walk in the park compared to this hell.
As you can explicitly set readout to 120fps it either works slower (why?) or faster (240fps declared in the same NX1 launch event that also declared CGRA). 
Cpu cores are most likely based on 1600MHz A9. 

Ok, few short notes. 
First of all, there are two operating systems running, tizen and t-kernel based real time OS. What we see and can access is just a nice front end that issues messages to RTOS that actually does all the hard work. If some function is not implemented in it it's unfeasible for us. 
Regarding GUI - I'm working on it now and it's the most hostile toolkit I have ever worked with - EFL. Android is walk in the park compared to this hell.
As you can explicitly set readout to 120fps it either works slower (why?) or faster (240fps declared in the same NX1 launch event that also declared CGRA). 
Cpu cores are most likely based on 1600MHz A9. 

Ok, few short notes. 
First of all, there are two operating systems running, tizen and t-kernel based real time OS. What we see and can access is just a nice front end that issues messages to RTOS that actually does all the hard work. If some function is not implemented in it it's unfeasible for us. 
Regarding GUI - I'm working on it now and it's the most hostile toolkit I have ever worked with - EFL. Android is walk in the park compared to this hell.
As you can explicitly set readout to 120fps it either works slower (why?) or faster (240fps declared in the same NX1 launch event that also declared CGRA). 
Cpu cores are most likely based on 1600MHz A9. 

Hi,
A nice breakthrough in hacking NX500 (and possibly NX1 - could someone try and report back?).
So, TLDR version first: I'm able to run a shell script off the SD card without hacking the firmware (and some other stuff). This is just a very modest start, now we need to do everything else. That said, this is a useful start as we can now play around without bricking cameras.
That was the moderately good news, the moderately bad news is that I'm absolutely swamped by work related stuff next few weeks.
Now for longer version:
First a small "hack": If you want to take a screenshot of your camera screen put a file named save_screen_enable.txt in the SD card root and every time you press EV+OK a file named OSD####.jpg will be saved to SD card root. save_screen_enable.txt will contain the integer of next image id (as bytes, not text).
Another small "hack": If you want to see how all the popups and notices look in all the languages (for any reson) put a file named qa.txt in the root of the SD card. When you power the camera on you will see a popup menu that enables you to access all the popups, etc, in camera (press up and down to change them, left and right to change the language). It's meant for quality assurance staff, but here it is.
If you like scrolling through the popups - that's fine. Even better is that the camera app crashes on popup 188 (of 189, go figure) and produces a lot of detailed logs on the SD card. These logs are named timestamp_{log,a7_log,a9_crash,a9_dlog,a9_dmesg}.info
If you take your sweet time analyzing these logs you will find that NX500 does not boot all that often - it hibernates and then wakes up when you power the camera on - cute - that's how it starts up in one second
Also, some RAM information: Total RAM is 512MB, reserved (buffer?) is 380MB. It fits nicely with known buffer limitations. It also means it's very very difficult to extend it to anything larger (maybe by eliminating allshare app or similar but that would give us a frame or two in RAW at best - hardly worth it).
How to run a shell script file:
1. Put file named "info.tg" on the SD card root with contents "nx_cs.adj" and a newline
2. Put file named "nx_cs.adj" (can use something else really) on the SD card root and put "shell script /mnt/mmc/test.sh" and a newline in it
3. Put file named "test.sh" (or whatever you put up there) on SD card root and put whatever bash shell commands you want to in it. Word of caution - it's easy to make a mistake - start small and work carefully
4. Put SD card in camera
5. Camera to AUTO mode (IIRC it works in any mode but whatever, it's in AUTO in the Service Manual)
6. Power on the camera and wait a bit (or a lot, it seems it's quite lazy with closing files and syncing, might do it for it by calling "sync" at the end)
7. Power the camera off (and wait for blinking light to stop blinking if it's blinking)
For example, if you put following in test.sh
st > /mnt/mmc/test
This is what you get on the output:
usage: st [command] [param]
Supported bult-in commands
    help        readl        writel        dump    
    gpio        hdmi        log        lcd    
    cap        pmu        clk        thread    
    key        firmware    util        app    
    leak        devman        stlcd        bat    
    rtc        tbm        micom        misc    
    oic        dvfs        adc    
I put a "ls -laR / > /mnt/mmc/test" and it did list the whole filesystem including /proc /sys /dev etc. And /etc tar also works.
I can see for example that every time process id 247 is given to /usr/apps/com.samsung.di-camera-app/bin/di-camera-app and it runs under root (almost everything does), dfmsd (that's the deamon that interprets commands in nx_cs.adj file that are read and sent by dfmstool - I will have to see what else I can do with it), /usr/apps/com.samsung.ap-setting-app/bin/ap-setting-app running with some access keys or hashed caller PIDs, etc, the works.
Only two modules are loaded (exfat_fs and exfat_core) but I guess we could compile anything we need and enable it in the future (usb audio anybody?).
That's it for now (and some time).
Oh, yeah, the touch screen does not work with info.tg or info.tgw present on the SD card.
Cheers,
Otto

Argh! I typed a silly long post and then hit backspace outside of this box and ... poof ... it's gone
OK, shorter version:
If you start telnet server as described and connect to camera you can do following:
killall dfmsd; sleep 2; dfmsd -p &
This will kill original dfms daemon and start a new instance that we can now use by dfmstool command that sends commands to daemon like this:
dfmstool -s "this is a command"
Be careful, as soon as it encounters an invalid command it stops processing all other commands so we need to do killall... to restart it (it does not affect the camera state).
The command we want is sys_param movie size 2560_1440_30p. Yup, it's still in the firmware, it has no crop and it supports peaking. Why they removed it from the menu I have no idea. It's labelled as MJPEG on screen but it records HEVC as others and is limited to 29:59.
dfmstool -s "sys_param movie size 2560_1440_30p"
Here's what ffmpeg has to say (I have to find a way to set the quality as well):
Stream #0:1(eng): Video: none (hvc1 / 0x31637668), 2560x1440, 11280 kb/s, 29.97 fps, 29.97 tbr, 120k tbn, 120k tbc
Oh, yeah, remember how there is no 1080p at 120fps in NX500? Think again:
dfmstool -s "sys_param movie size 1920_1080_120p"
And output of ffmpeg:
Stream #0:0(eng): Video: none (hvc1 / 0x31637668), 1920x1080, 38589 kb/s, 119.88 fps, 119.88 tbr, 120k tbn, 120k tbc
If you really want to you can put just the command in the nx_cs.adj file and call it a day (dfmsd will parse it and finish) or put a small script in test.sh that will do it for you (there is no touchscreen available while dfmsd is running). You could have SD cards for special video modes to simplify it.
For NX500 full list of modes is
4096_2160_24p
3840_2160_30p
2560_1440_30p
1920_1080_120p
1920_1080_60p
1920_1080_30p
1920_1080_24p
1920_1080_15p
1280_720_120p
1280_720_60p
1280_720_30p
640_480_60p
640_480_30p
For NX1, full list of modes is (yeah fractional ones too, don't know whether they are just for show or are there really differences between 24 and 23.98 when recorded)
4096_2160_24p
3840_2160_30p
3840_2160_24p
3840_2160_23_98p
1920_1080_120p
1920_1080_60p
1920_1080_30p
1920_1080_24p
1920_1080_23_98p
1920_1080_15p
1280_720_60p
1280_720_30p
640_480_60p
640_480_30p
Well, that's it for now, have fun

Argh! I typed a silly long post and then hit backspace outside of this box and ... poof ... it's gone
OK, shorter version:
If you start telnet server as described and connect to camera you can do following:
killall dfmsd; sleep 2; dfmsd -p &
This will kill original dfms daemon and start a new instance that we can now use by dfmstool command that sends commands to daemon like this:
dfmstool -s "this is a command"
Be careful, as soon as it encounters an invalid command it stops processing all other commands so we need to do killall... to restart it (it does not affect the camera state).
The command we want is sys_param movie size 2560_1440_30p. Yup, it's still in the firmware, it has no crop and it supports peaking. Why they removed it from the menu I have no idea. It's labelled as MJPEG on screen but it records HEVC as others and is limited to 29:59.
dfmstool -s "sys_param movie size 2560_1440_30p"
Here's what ffmpeg has to say (I have to find a way to set the quality as well):
Stream #0:1(eng): Video: none (hvc1 / 0x31637668), 2560x1440, 11280 kb/s, 29.97 fps, 29.97 tbr, 120k tbn, 120k tbc
Oh, yeah, remember how there is no 1080p at 120fps in NX500? Think again:
dfmstool -s "sys_param movie size 1920_1080_120p"
And output of ffmpeg:
Stream #0:0(eng): Video: none (hvc1 / 0x31637668), 1920x1080, 38589 kb/s, 119.88 fps, 119.88 tbr, 120k tbn, 120k tbc
If you really want to you can put just the command in the nx_cs.adj file and call it a day (dfmsd will parse it and finish) or put a small script in test.sh that will do it for you (there is no touchscreen available while dfmsd is running). You could have SD cards for special video modes to simplify it.
For NX500 full list of modes is
4096_2160_24p
3840_2160_30p
2560_1440_30p
1920_1080_120p
1920_1080_60p
1920_1080_30p
1920_1080_24p
1920_1080_15p
1280_720_120p
1280_720_60p
1280_720_30p
640_480_60p
640_480_30p
For NX1, full list of modes is (yeah fractional ones too, don't know whether they are just for show or are there really differences between 24 and 23.98 when recorded)
4096_2160_24p
3840_2160_30p
3840_2160_24p
3840_2160_23_98p
1920_1080_120p
1920_1080_60p
1920_1080_30p
1920_1080_24p
1920_1080_23_98p
1920_1080_15p
1280_720_60p
1280_720_30p
640_480_60p
640_480_30p
Well, that's it for now, have fun

Argh! I typed a silly long post and then hit backspace outside of this box and ... poof ... it's gone
OK, shorter version:
If you start telnet server as described and connect to camera you can do following:
killall dfmsd; sleep 2; dfmsd -p &
This will kill original dfms daemon and start a new instance that we can now use by dfmstool command that sends commands to daemon like this:
dfmstool -s "this is a command"
Be careful, as soon as it encounters an invalid command it stops processing all other commands so we need to do killall... to restart it (it does not affect the camera state).
The command we want is sys_param movie size 2560_1440_30p. Yup, it's still in the firmware, it has no crop and it supports peaking. Why they removed it from the menu I have no idea. It's labelled as MJPEG on screen but it records HEVC as others and is limited to 29:59.
dfmstool -s "sys_param movie size 2560_1440_30p"
Here's what ffmpeg has to say (I have to find a way to set the quality as well):
Stream #0:1(eng): Video: none (hvc1 / 0x31637668), 2560x1440, 11280 kb/s, 29.97 fps, 29.97 tbr, 120k tbn, 120k tbc
Oh, yeah, remember how there is no 1080p at 120fps in NX500? Think again:
dfmstool -s "sys_param movie size 1920_1080_120p"
And output of ffmpeg:
Stream #0:0(eng): Video: none (hvc1 / 0x31637668), 1920x1080, 38589 kb/s, 119.88 fps, 119.88 tbr, 120k tbn, 120k tbc
If you really want to you can put just the command in the nx_cs.adj file and call it a day (dfmsd will parse it and finish) or put a small script in test.sh that will do it for you (there is no touchscreen available while dfmsd is running). You could have SD cards for special video modes to simplify it.
For NX500 full list of modes is
4096_2160_24p
3840_2160_30p
2560_1440_30p
1920_1080_120p
1920_1080_60p
1920_1080_30p
1920_1080_24p
1920_1080_15p
1280_720_120p
1280_720_60p
1280_720_30p
640_480_60p
640_480_30p
For NX1, full list of modes is (yeah fractional ones too, don't know whether they are just for show or are there really differences between 24 and 23.98 when recorded)
4096_2160_24p
3840_2160_30p
3840_2160_24p
3840_2160_23_98p
1920_1080_120p
1920_1080_60p
1920_1080_30p
1920_1080_24p
1920_1080_23_98p
1920_1080_15p
1280_720_60p
1280_720_30p
640_480_60p
640_480_30p
Well, that's it for now, have fun

OK, an update:
If you want to experiment with your device but don't want to be constantly reinserting the SD card - here's the solution.
First, unfortunately, NX500/NX1 do not use busybox but toybox that does not contain telnetd. However, there is nothing stopping you from extracting it from NX300 open source packages (available at Samsung Open Source repo) and copying it to SD card (and naming it "telnetd") and runnig it from there. Just remember that you need to give yourself some time to turn the wifi on after powering the camera. Login is "root" and there is no password. So, after the camera boots and telnetd starts, you do
telnet 192.168.1.44
Trying 192.168.1.44...
Connected to 192.168.1.44.
Escape character is '^]'.

************************************************************
*                 SAMSUNG LINUX PLATFORM                   *
************************************************************

drime5 login: root
[root@drime5 ~]# ps aux
USER      PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root        1  0.4  0.2   4684  1452 ?        Ss   23:15   0:01 /sbin/init
root        2  0.0  0.0      0     0 ?        S    23:15   0:00 [kthreadd]
root        3  0.0  0.0      0     0 ?        S    23:15   0:00 [ksoftirqd/0]
...
root      363  0.1  0.0      0     0 ?        S    23:15   0:00 [ksdioirqd/mmc1]
root      399  0.0  0.0   4696   380 ?        S<s  23:16   0:00 /mnt/mmc/telnetd
root      402  0.0  0.2   2704  1352 pts/0    S<s  23:16   0:00 -sh
root      469  3.0  0.1   2664   904 pts/0    R<+  23:20   0:00 ps aux
Yippie - we have remote root!
The fun stuff is the command st. It's swiss army knife - it contains everything. For example, you want to take a "smart" shot?
st cap capt smart
Work with aperture?
st cap capt iris drive 7.1
Shoot in RAW?
st cap capt quality raw
Help works in most things, just add help (e.g. st cap capt help).
You want to push an OK button?
st key click ok
You can also push/release it in two steps.
How about jog dials?
st key jog jog1_cw or jog1_ccw
You want to touch the screen in exact coordinates?
st key touch push/release/click 400 300
There is so many things available, just explore st app nx capture (for stills) or st app nx record (for video)...