| Age | Commit message (Collapse) | Author |
|---|
|
When you depend on the shortcuts as _the_ means of
stopping/pausing a recording, like in a WM integration scenario,
it's preferable to have rmd exit fatally when the grabs can't be
setup. (usually this occurs when you've accidentally tried
starting multiple recordings, and the shortcuts collide)
This way, the integration can detect the failure and throw up a
dialog or something informing the user that the recording wasn't
started. All that's needed is including --need-shortcuts.
Note this is a little janky in how it's implemented, because
XSetErrorHandler() is janky and doesn't even support a user
pointer payload.
Rather than introducing global variables to either communicate
the grab failures to other parts of rmd, or exposing the parsed
args struct to the error handler globally in the other direction,
I just made a grab-errors-are-fatal variant of the handler which
gets installed when --need-shortcuts is specified.
|
|
This changes --use-jack PORT to expect a single port in its
argument, since popt doesn't really support what was being
attempted.
Instead, to specify multiple JACK ports, you just repeat
--use-jack PORTN N times, e.g:
--use-jack system:capture_1 --use-jack system:capture_2
This way we don't get into the business of parsing multiple ports
from a single argument, and picking which separator to use. It
appears JACK port names don't have any reserved characters,
judging from the API docs and a brief perusal of the code. So we
couldn't even pick a bulletproof separator if we wanted to.
Fixes https://github.com/recordmydesktop/recordmydesktop/issues/8
Jack support is totally untested in my fork so it's largely
as-inherited still.
|
|
Trivial cosmetic changes noticed while glancing at --help
|
|
Mostly trailing space/tab removals, no functional changes.
|
|
This adds a new flag:
--periodic-datasync-ms
with a default of 100ms.
When a new CacheFile is created for writing, and the datasync
period is non-zero, a thread is created for the sole purpose of
calling fdatasync() on the underlying fd in a loop separated by
sleeps of the specified duration.
The purpose of this is to prevent a large backlog of dirty
buffers from accumulating until the operating system's normal
background dirty sync kicks in. Depending on how the underlying
filesystem and storage stack is configured, these bulk writebacks
can result in very long stalls on a subsequent write operation.
This is easily observed on ext4+lvm+dmcrypt setups, even using a
simple test like `dd if=/dev/urandom of=testfile bs=8M`. Despite
having plenty of available buffers, once ext4's internal journal
fills while a bulk writeback is underway, dd's progress will
completely stall until the entire writeback is completed, usually
it's in the jbd2 wchan of do_get_write_access().
When this occurs during a recording by recordMyDesktop, the
result is dropping frames for the entire duration of the stall.
One thing recordMyDesktop could do to insulate from this is
perform its own buffering of sampled frames at the YUV stage,
with the cache writer consuming from this pool of buffered
frames. Then when the cache writer gets stalled on jbd2/dmcrypt
holdups, the buffer pool just grows instead of frames being
dropped. I may explore this option in the future, but for now
simply syncing regularly has been sufficient in my usage, as it
keeps the storage subsystem more continuously utilized and
spreads out the writebacks so they don't completely back up the
journal.
|
|
Making things a bit more consistent
|
|
This restores the recordmydesktop/ subdir as root from the mirror I
cloned by fork from.
I have no particular interest in the gtk/qt frontends and it doesn't
appear they were part of a single tree in the past. But I will
probably preserve backwards compatibility of the cli so they can
continue to work with this fork installed.
|
