summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Document using GP_CAMLIB_SET on make command lineHans Ulrich Niedermann2021-08-272-3/+6
| | | | | | | | Documents the use of GP_CAMLIB_SET on the make command line. Setting CAMLIBS= on the make command line to specify the set of camlibs to be built and installed has not worked at least since the introduction of GP_CAMLIB_SET.
* for sony preview capture use a timeout of 1 secondMarcus Meissner2021-08-251-1/+4
| | | | might help https://github.com/gphoto/libgphoto2/issues/693
* added fuji gfx100 second id reported via SFMarcus Meissner2021-08-251-0/+2
|
* factor out regular image additions repeated codeMarcus Meissner2021-08-221-32/+33
|
* move another preview jpeg extractor to factorized functionMarcus Meissner2021-08-221-10/+5
|
* use generic preview.jpg name, not sony for ... fujiMarcus Meissner2021-08-211-1/+1
|
* further factor out the preview saving and meta data setting, as its commonMarcus Meissner2021-08-211-57/+34
|
* factorize out the jpeg extraction out of data blobsMarcus Meissner2021-08-211-100/+54
|
* emit also new values in the config update work (draft work) ↵Marcus Meissner2021-08-181-6/+6
| | | | https://github.com/gphoto/libgphoto2/issues/677
* trying to fix eos readerMarcus Meissner2021-08-171-0/+1
|
* srtore DevPropCode, needed by current config name matcherMarcus Meissner2021-08-171-0/+1
|
* more debug, also switch conditions to avoid O(n2) complexityMarcus Meissner2021-08-171-7/+8
|
* added property change decoding to EOS and OlympusMarcus Meissner2021-08-171-8/+38
|
* decode value of regular widgetsMarcus Meissner2021-08-171-4/+76
|
* Merge branch 'master' of github.com:gphoto/libgphoto2Marcus Meissner2021-08-171-0/+2
|\
| * Add add missing ISO values from Canon EOS R6Daniel Schulte2021-08-121-0/+2
| | | | | | The Canon EOS R6 has two additional ISO values that were not supported before: 64000 and 80000.
* | report changed config labels during waitMarcus Meissner2021-08-173-6/+176
| | | | | | | | https://github.com/gphoto/libgphoto2/issues/677
* | remove memory leaksMarcus Meissner2021-08-101-1/+7
|/
* INSTALL: add gtk-doc Debian package nameHans Ulrich Niedermann2021-08-101-0/+1
| | | | Closes: https://github.com/gphoto/libgphoto2/pull/320
* gh workflows: remove requirements for flex, bisonHans Ulrich Niedermann2021-08-072-2/+2
| | | | | | | As 4316f75ed4ce7a4ae5296264699665631c4e62d6 has removed gp2ddb with its use of flex and bison, we do not need flex and bison any more, and so the github workflows do not need to install flex and bison either.
* Add HDR exposure mode from EOS RPJan Kundrát2021-08-071-0/+1
| | | | | It's present in the `autoexposuremode` when the mode dial is set to Movie and the HDR movie mode is enabled via the camera menu.
* Add mode dial positions available on EOS RP or 5DivJan Kundrát2021-08-071-0/+4
| | | | | | | | | I picked C2 and C3 while the existing one is called "Custom"; I think the naming is a bit ad hoc (full words like "Manual" and "Bulb" vs. all-caps abbreviations "AV" and "TV" vs. "Fv" which is spelt as-is on the mode dial). Tested on EOS RP, 5Div and 5Diii.
* Canon: basic control over Movie Servo AFJan Kundrát2021-08-072-0/+8
| | | | | | | | | | | | This supports just the Enabled/Disabled choices as defined in the camera menu (on RP, Menu -> Shooting -> 5 -> Movie Servo AF). Even when active, the servo AF can be suspended by tapping the LCD screen at the bottom left corner with a green "SERVO AF" button; I do not see any PTP property getting changed upon suspend/resume. Tested on EOS RP and on 5Div. Related-bug: #700
* Use AC_SEARCH_LIBS to find where mmap(2) is definedHans Ulrich Niedermann2021-08-072-6/+16
| | | | | | | | | | Use AC_SEARCH_LIBS to find whether mmap(2) in the standard library, or whether using mmap(2) requires linking against libmman. This avoids conditionally calling/expanding AM_CONDITIONAL which autoreconf (rightly) complains about. This also uses proper m4 quoting in all m4 macro arguments.
* Fixed build in mingwJaroslav Škarvada2021-08-074-4/+16
| | | | Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
* camlibs/ptp2/ptp-pack.c: Fix aperture on EOS RPJan Kundrát2021-08-061-5/+1
| | | | | | | | | | | | | My wife's EOS RP (FW 1.4.0) always reports the lens' lowest aperture unless we apply the same special handling which is enabled for `olcver == 0x13` (apparently, EOS R5). Tested with RF 35/1.8, and also on 5Div + Sigma 35 Art (to check a possible regression). This reverts commit 5bf98e7f09e82d0e27f41a8df4ccb10e5feb6944 (and fixes a comment so that it more accurately reflects what's going on). I'm a bit nervous about this because that commit looks like it was explicitly designed to do the exact opposite of this one, but perhaps it was just to be extra cautious?
* temporary allow setting all properties on sony, as ourdetection logic does ↵Marcus Meissner2021-08-011-1/+3
| | | | not seem to be right.
* Add few more movie modes for SonyIngvar Stepanyan2021-08-011-1/+6
|
* Add Sony a6600 descriptorsIngvar Stepanyan2021-08-011-0/+6
| | | Without this, camera abilities would report a6600 as not having "trigger capture" even though it works on practice.
* fixed some memory leaks caused by ptp_getobjectinfo imbalanced with ↵Marcus Meissner2021-07-231-4/+25
| | | | ptp_free_objectinfo, see https://github.com/gphoto/libgphoto2/issues/690
* Fix memory leak in capture preview for SonyIngvar Stepanyan2021-07-231-0/+2
| | | | | | | | | | | | | | I've noticed consistent memory increase while streaming preview from a Sony camera. Building with `-fsanitize=leak` revealed that the leak is coming from `strdup <- ptp_unpack_string <- ptp_unpack_OI <- ptp_getobjectinfo`. Apparently, `PTPObjectInfo` contains heap-allocated strings for `Filename` & `Keywords`, and so `ptp_free_objectinfo` always must be called on the `ptp_getobjectinfo` results. That all sounds good, but what seriously worries me is that, after fixing this particular codepath for PTP_VENDOR_SONY, I've searched for other usages of `ptp_getobjectinfo`, and majority of them don't ever call `ptp_free_objectinfo` on the result. That is, there's probably tons of other leaks out there for various cameras just out of this single call, and someone needs to go through all those usages and fix them one by one. While it might be a simple refactoring, it requires great care and I'm not ready to invest into it especially when there's no way of testing the result with other camera models. Perhaps a more systematic fix is necessary - for example, `PTPObjectInfo` could be changed to contain fixed-length char arrays and sidestep this problem altogether. More generally, it might be also worth running GPhoto's tests with address & leak sanitizers enabled to detect all such similar problems.
* make the textual description of syncdatetimeutc also mention UTCMarcus Meissner2021-07-201-1/+1
| | | | fixes https://github.com/gphoto/libgphoto2/issues/684
* added more braces to the new expressions to make clear what we testMarcus Meissner2021-07-151-3/+3
|
* Normalize Sony shutter speedsIngvar Stepanyan2021-07-151-0/+15
| | | | | | | | Apparently Sony reports shutter speeds that are integer seconds as "300/10", "250/10", "200/10" etc. This happens both on Sony a6600 I currently have as well as I can see this when searching for 0xd229 among camlibs/sony-*.txt - that is, even models with enums use this format. Interestigly, setting shutter speeds accept either form, so what happened is you could set shutter speed to e.g. "5" and camera would change it, but then camera would report back "50/10" which is no longer valid value for the shutter speed widget. This PR normalizes all such shutter speeds to their integer form, so that "5" would be reported back as well in such scenario.
* Remove duplicate GP_MIME_ARWIngvar Stepanyan2021-07-141-1/+0
| | | Apparently GP_MIME_ARW was already there just unused in the function.
* Add file extension for Sony ARW filesIngvar Stepanyan2021-07-142-0/+2
|
* Mark properties without setters as readonlyIngvar Stepanyan2021-07-142-0/+13
| | | | | | Without this, widgets for things like "Serial Number", "Manufacturer", "Battery level" etc. would be created as writable, even though they are not. It it possible to special case them in GUI frontends when rendering (e.g. by making everything under "status" section readonly anyway), but it seems better to return correct readonly status for such properties from libgphoto2 itself.
* Fix overshoot logic for Sony enumsIngvar Stepanyan2021-07-121-17/+26
| | | | | | | | Overshoot logic was always comparing values to determine if the desired target has been overshot. However, in case of enums this didn't work correctly, since enum values are not guaranteed to be in the sorted order. For example, "Auto ISO Multi Frame Noise Reduction" has a higher numerical value than, say, "ISO 400 Multi Frame Noise Reduction" but comes earlier in the enum list, so trying to go from "ISO 102400" to "ISO 400 Mutli Frame Noise Reduction" would stop at "Auto ISO Multi Frame Noise Reduction" thinking that the value has been overshot and can't go any further. This PR fixes the logic to use enum index for overshot comparisons instead when `useenumorder` is enabled.
* use the large jump on first try, fall back to single jumps on next loopsMarcus Meissner2021-07-091-12/+15
| | | | https://github.com/gphoto/libgphoto2/pull/676
* Fix infinite loop when setting Sony valuesIngvar Stepanyan2021-07-091-2/+12
| | | | | | An example where I ran into this: Sony a6600 reports values [25, 50, 64, 80, 100, 125, 160, 200, 250, 320, 400, ...] as supported with Multi Frame Noise Reduction. However, among those values the camera only allows selecting between [100, 200, 400]. As a result, switching even between valid values - say, ISO 100 with MFNR and ISO 3200 without MFNR - was calculating incorrect offset, overshooting in one direction, calculating new incorrect offset, overshooting in another direction, and so on leading to an infinite loop.
* Revamp Sony ISO logicIngvar Stepanyan2021-07-0912-225/+249
| | | | | - Add support for distinguishing Standard vs High modes for Multi Frame Noise Reduction. Previously those would be rendered as separate options with the same name, making it impossible to choose the correct one or switch from one to another. Now the high mode is indicated by the `+` suffix. - Fix higher ISO values for MFNR too. Previously a mask 0xffff was used, which was incorrect and didn't cover higher ISO values. Instead, base ISO should be read with 0x00ff_ffff mask, and the highest byte then indicates the MFNR mode (0 for disabled, 1 for Standard, 2 for High). This also simplifies the logic for Auto ISO, since it's correctly covered by the updated mask.
* harmoize the jpeg extractors pointer arithmetic for memchr to be valid CMarcus Meissner2021-07-091-9/+9
|
* Provide correct search size to memchrIngvar Stepanyan2021-07-091-1/+1
| | | | | | | https://github.com/gphoto/libgphoto2/commit/6c26cdc5b0b8f177bb0d74ea93c8f0d45afb3a09 adjusted `jpgStartPtr` to start after an offset if such is found in the initial blob. The following `memchr` call was changed to use the adjusted `jpgStartPtr` pointer, but the size parameter was never changed, in theory allowing `memchr` to search in the garbage area past the allocation. On practice this shouldn't matter because during the previous adjustment it's checked that the following bytes are indeed 0xFF 0xD8 so memchr loop should stop right away, but 1) in theory vectorized memchr might try to read more if it thinks there's enough data to parallelise operations, 2) this can be error-prone in the future and 3) I actually ran into an issue here in combination with a buggy `memchr` implementation in one compiler (which is, admittedly, unrelated issue and I reported it separately).
* added a7s dataMarcus Meissner2021-07-061-0/+1152
|
* allow cancel for bytes_read >= 1MB to cover blob read size in ptpMarcus Meissner2021-06-201-2/+3
| | | | fioxes https://github.com/gphoto/libgphoto2/issues/665
* sierra: Add curly braces to improve code readabilityOndrej Zary2021-06-191-1/+2
|
* sierra: Add SIERRA_PACKET_CANCEL (0x18) as valid resonseOndrej Zary2021-06-191-0/+3
| | | | | | | | At least Epson PhotoPC 500 with firmware v22-75 responds with 0x18 to the "folder support". This is not recognized as a valid response, resulting in retries and delay. Add SIERRA_PACKET_CANCEL (0x18) and recognize it as valid reject response.
* sierra: Add workaround for Epson PhotoPC 500 at higher speedsOndrej Zary2021-06-193-2/+27
| | | | | | | | | | | At least Epson PhotoPC 500 with firmware v22-75 fails to work above 38400bps - all commands time out. Seems that we're sending data too fast (and there's no flow control). Do the same thing as Windows driver: when the first command (reading register 1) times out after 500ms, switch to writing one byte at a time. Maybe this could also fix cameras that use SIERRA_LOW_SPEED or SIERRA_MID_SPEED now?
* added eos1300dMarcus Meissner2021-06-191-0/+1809
|
* updated NEWSMarcus Meissner2021-06-191-0/+12
|
View Lorry Controller Status