summaryrefslogtreecommitdiff
path: root/recordmydesktop
AgeCommit message (Collapse)Author
2020-07-11get_frame: more unfucking synchronizatoinVito Caputo
2020-07-11get_frame: s/blocknum_[xy]/blocks_[wh]/Vito Caputo
Minor cleanup
2020-07-11make_dummy_pointer: more formatting cleanupsVito Caputo
Nothing functionally changed
2020-07-11rescue: more formatting cleanupsVito Caputo
nothing functionally changed
2020-07-11cache: more formatting cleanupsVito Caputo
nothing functional changed
2020-07-11initialize_data: more formatting cleanupsVito Caputo
Nothing functionally changed
2020-07-11rectinsert: stop aligning rects on insert hereVito Caputo
Assume rects that come in for insertion are already as aligned as possible within the rrect bounds. If the rrect has odd dimensions, then there's potential for edge case odd rects too - but the only even-sensitive code is the YUV updating and that's been amended to at least ignore those edge cases gracefully. Also constify the supplied xrect while in here.
2020-07-11poll_events: align rectangles to even boundariesVito Caputo
The current rectinsert code does this, but it does it in the absolute root window coordinate space. In preparation for dropping all the alignment stuff out of rectinsert, do the alignment at the rectinsert caller and do it in the rrect-relative coordinate space.
2020-07-11get_frame: consolidate [yuv]blocks reset as a funcVito Caputo
Eliminate some pointless duplication
2020-07-11update_image: add some asserts on clipped rectVito Caputo
Just some sanity checks to ensure clipping is working properly
2020-07-11capture_sound: simplify locking and buffer acquisitionVito Caputo
More tidying of things
2020-07-11get_frame: perform shmctl(IPC_RMID) after shmat()Vito Caputo
No need to duplicate this down at the teardown, it won't go away with outstanding references so you can basically queue the rm.
2020-07-11*: introduce Image typeVito Caputo
Baby step towards encapsulating the shmem and ximage state
2020-07-11cache_frame: calculate size from yuv dimensionsVito Caputo
More preparation for yuv and rrect dimensions differing
2020-07-11*: more random minor cleanupsVito Caputo
Nothing significant
2020-07-11*: more random cleanupsVito Caputo
minor formatting/whitespace changes
2020-07-11yuv_utils: shrink [yuv]blocks to unsigned char[]Vito Caputo
No idea why this had such a large type, its members just hold 0 or 1.
2020-07-11yuv_utils: gracefully ignore odd pixels for UVVito Caputo
This is temporary, in preparation for potentially odd-dimensioned image buffers. For now I'll just skip the last row / column in the UV update for such odd dimensions. In the future there could be a read-modify-write dance for handling the last row/column or something like that.
2020-07-11yuv_utils: fixup dirty blocknum() parametersVito Caputo
This needs to maintain dirty blocks in the yuv frame coordinates, not in the captured image's cooridinates. The existing code assumes those are the same in double-buffer mode where the dirty block tracking is applied. But I'm working towards allowing the captured image dimensions to be free from the 16x16 alignment constraints the yuv buffers must conform to for theora. To handle that future, the block coordinates should at least use the (yuv)->y_width, not width_tm. I also added shifting the x,y but in double-buffer mode that shouldn't actually be needed since it'd always be full-shots unless I'm mistaken.
2020-07-11yuv_utils: more cleanups focusing on the macrosVito Caputo
Nothing really changed here, just rearranging some stuff and replacing some divides with shifts.
2020-07-11getzpixmap: remove pointless _XReadPad()Vito Caputo
No idea why rmdGetZPixmapSHM() is doing this, the whole point of shmem is to not have to read the data over the wire. You request the server to do the copy into the shared memory and that's all there is to it. This program is so confused
2020-07-11get_frame: replace XCreateImage++ w/XGetImageVito Caputo
Remove more pointless code
2020-07-11get_frame: remove pointless XInitImage()Vito Caputo
XCreateImage() returns a fully initialized ready-to-use XImage, I have no idea why the author did this.
2020-07-11*: more small whitespace fixupsVito Caputo
nothing functionally changed
2020-07-11get_frame: more cleanupsVito Caputo
nothing functionally changed
2020-07-11*: more random formatting cleanupsVito Caputo
nothing functionally different
2020-07-11TODO: replace useless TODO contents with --unmuteVito Caputo
2020-07-11load_cache: more formatting cleanupsVito Caputo
nothing functionally changed
2020-07-11cache_frame: more formatting cleanupsVito Caputo
Mostly mindless whitespace fixups but also changed some yuvblocks indexing that seemed brain damaged to just be simpler without actually changing anything functionally
2020-07-11parseargs: fix obvious typo in long form of -yVito Caputo
This explains why I've seen errors using --long arguments consistently even for --x and --y. I had assumed --x and --y weren't supported but it turns out it's just what looks to be a copy and paste error. Man this source has been such a disaster area.
2020-07-11*: more random cleanups mostly formattingVito Caputo
nothing functionally different
2020-07-11getzpixmap: more formatting cleanupsVito Caputo
2020-07-11get_frame: de-macroify CLIPPY_DUMMY_POINTER_AREAVito Caputo
Zero reason for this to be an unreadable macro, make function and try format sanely I didn't really change it other than passing the clip rect instead of brwin
2020-07-11get_frame: demacroify MARK_BUFFER_AREAVito Caputo
Convert macro to function and format retained macro portion
2020-07-11encode_sound_buffer: more unfucking synchronizationVito Caputo
again leaving libjack related stuff for later
2020-07-11cache_audio: more unfucking of synchronizationVito Caputo
leaving the libjack related fixes for later
2020-07-11get_frame: pass rect to rmdMoveCaptureAreaVito Caputo
Just simplifying this function to not need brwin-> everywhere while cleaning up the formatting
2020-07-11*: more random formatting cleanupsVito Caputo
Nothing really changed here, but I suspect the {row,column}_end + 1 conditions in rmdBlocksFromList() are buggy and shouldn't have the +1. Left as-is for now.
2020-07-11*: more random formatting cleanupsVito Caputo
some theora init error checking fixups snuck in there as well
2020-07-11update_image: simplify rmdUpdateImage()Vito Caputo
removing some unnecessary nesting
2020-07-11*: try restore some sanity to YUV macrosVito Caputo
The public macros didn't need to be macros, so they've been turned into functions. All the big ugly YUV macro stuff that can be justified as macros has been moved to rmd_yuv_utils.c where they're privately used. They've also had a first pass at formatting them sanely...
2020-07-11rmd: zero initialize core structsVito Caputo
2020-06-23poll_events: fix and de-macroify CLIP_EVENT_AREAVito Caputo
I don't know why the author was so obsessed with macros where they served to only make impossible to read and maintain, bringing zero benefit. This turned out to have some bugs so I rewrote some of it while converting to a function.
2020-06-23rmd_cache: silence compiler warnings about gzFileVito Caputo
zlib typedefs gzFile to already be a pointer to the struct, so these shouldn't have two pointers on the fp, one comes with the type.
2020-06-23*: more code and synchronization cleanupsVito Caputo
Not going to bother with granular commit messages yet, not til things get reasonably sane
2020-06-23*: first attempt to unfuck thread synchronizationVito Caputo
I'm already regretting this... I don't think the author understood how condition variables work, that signal/broadcast is purely synchronous with blocked waiters - they don't queue a "signaled" state. So all these cond_waits littered everywhere without any explicit stateful condition being watched, if they didn't happen to be sitting in the wait when the signal occurred, that signal event was lost, and blocking would persist until the next one. Even if the wait only *just* missed the arrival due to scheduling, it was a very racy and broken use of condition variables. Not to mention the possibility of spurious wakeups... You *always* need some shared state to use condition variables properly, it's why they include a mutex; to protect the shared state. If you're not writing a while() loop to wait on a condition variable, you're almost certainly doing it wrong. This stuff will continue to evolve as I get around to it.
2020-06-20setbrwindow: yank nbytes out of BRWindow structVito Caputo
This only gets used in one place and isn't even relevant for shmem scenarios where the size in bytes depends on the bytes per row from the server. For now I'm just moving its simple computation to where it's used, as-is. It seems to be doing some 16-byte alignment dance as well which... seems very odd. If the sizes were already getting 16-byte aligned, why do this again? I fully expect to throw the alignment shit out at some point, as this all gets reworked. The way this was done seems completely misguided... the Theora alignment considerations should be handled in the YUV buffer, since the copy needs to be made from the XImage in all cases - shmem and non, to convert to YUV, the YUV buffer should have been sized to accomodate Theora, and the RGB->YUV conversion-copy should pad out the aligned target buffer as needed.
2020-06-20get_frame: simplify rmdBRWinCpyVito Caputo
There's no need to copy all the members of the nested rects, just copy the whole structs.
2020-06-20brwin: s/.rect/.winrect/Vito Caputo
Disambiguate this member name a bit from the other .rect uses, just to make things a bit easier to search for.
2020-06-20*: just some fast and nasty reformattingVito Caputo
If I'm going to actually be modifying this program substantially and possibly maintaining some fork of it, it's gotta be formmatted how I prefer. This is by no means done or perfect, rmd_types.h in particular is quite the mess, I will be revisiting this issue...
© All Rights Reserved