b) a patch that adds a 'clear halt and retry' behaviour to the write
path in an analogous way to the already existing read path. this patch
removes the error (that got nicely logged with the first patch ;))
git-svn-id: https://svn.code.sf.net/p/gphoto/code/trunk/libgphoto2@15111 67ed7778-7388-44ab-90cf-0a291f65f57c
rewrote the ptp_opensession error retry code
changed some more error logging handling
detailed:
a) yet another logging/cleanup patch improving the code and error log
readability in this specific situation:
* extend translate_ptp_results to better handle PTP_ERROR_IO
* log the failure of ptp_opensession
* make the ptp_opensession error handling code clearer
* don't report a 'ptp_port' error inside the CHECK_INIT macro
when gp_camera_init fails in gphoto-camera.c. There is no
port error string mechanism involved and the original error has
been reported already from inside camera_init
* don't report the source location when logging the error string
inside gp_context_error(). interesting would be the original
source location but that is not available there.
* remove one of two different strings conveying the same
information: 'No additional information available.' and
'No error description available'
* improve logging in existing CHECK_RESULT_OPEN_CLOSE macro
git-svn-id: https://svn.code.sf.net/p/gphoto/code/trunk/libgphoto2@15110 67ed7778-7388-44ab-90cf-0a291f65f57c
I had something 'prepared' for this situation, here you go.. ;)
The patch does not, however, actually remove the GP_LOG_VERBOSE enum,
since that would change the interface for all clients, which might not
be worth it. If you don't think that is a problem, please remove it...
git-svn-id: https://svn.code.sf.net/p/gphoto/code/trunk/libgphoto2@15107 67ed7778-7388-44ab-90cf-0a291f65f57c
here are the logging cleanup patches for the remaining libgphoto_port
backend libs, that I announced earlier.
14 and 15 are equivalent to 3,4,5 as before.
16 removes 4 left instances of _(...) macro usage in log messages.
git-svn-id: https://svn.code.sf.net/p/gphoto/code/trunk/libgphoto2@15106 67ed7778-7388-44ab-90cf-0a291f65f57c
I added a LOG_ON_PTP_E mechanism similar to the LOG_ON_LIBUSB_E one.
This further increases consistency in error reporting in places where
the C_PTP_... macros could not be used. I used the macro mainly where
there have been existing checks for != PTP_RC_OK. There might be a lot
other, yet unchecked places, where this macro could be useful.
I also tuned some of the error/debug messages with the same goal (like
replacing '%x' with '%04x' in the C_PTP_ macros) or adding the
ptp_strerror where appropriate.
Please note, that both the 'inline' and the 'static' keyword in front
of the log_on_ptp_error_helper() function definition are of use here,
to make the compiler not warn about unused functions or functions
without prototype.
git-svn-id: https://svn.code.sf.net/p/gphoto/code/trunk/libgphoto2@15104 67ed7778-7388-44ab-90cf-0a291f65f57c
1) introduce C_PARAMS and C_PARAMS_MSG along the lines of C_MEM
2) replace CHECK_NULL with C_PARAMS
3) replace the pattern
if ( something ) return GP_ERROR_BAD_PARAMETERS;
with
C_PARAMS ( !something );
I went over the whole patch again to check that each 'something'
condition is really inverted, so I dare to suggest you don't have to
do that again ;).
4) replaced CHECK_LIST and CHECK_INDEX_RANGE with simple one-line
C_PARAMS(...) expressions
5) a couple of hunks look like this
- if (!inet_aton (buffer, &inp)) {
- fprintf(stderr,"failed to scan for addr in %s\n", buffer);
- return GP_ERROR_BAD_PARAMETERS;
- }
+ C_PARAMS_MSG (inet_aton (buffer, &inp),
so some 'lost' error messages get now properly piped into the gp_log
mechanism.
git-svn-id: https://svn.code.sf.net/p/gphoto/code/trunk/libgphoto2@15103 67ed7778-7388-44ab-90cf-0a291f65f57c
A gphoto user has contacted me about getting what appears to be a new
version of a st2205 picture frame working with gphoto. The st2205 frames
use a rather funky image compression which involves 2 lookup tables:
1) lookup table with 8 byte patterns, a check is done if color
gradients in these blocks are close to a set of fixed patterns, if
they are they the block gets encoded in as a base color + gradient
pattern number
2) These devices do a number of transition effects, these effects
are part of the encoding, the transitions are mainly done to
hide the slowness of the device and the 8x8 blocks are stored
in transition order, so the first block to be shown is the first
one in the data stream, second block to be shown second, etc. This
means we need to know the location where each block will end up
on the screen to compress / decompress. There are a number of
fixed tables for this (1 set of tables per supported resution,
with 1 table per effect number).
So far we've been reading these tables from the firmware image
which can be accessed through the same interface as the picture
memory on these devices. But this new device does not have these
tables in its memory in any recognizable form.
This commits adds the necessary tables directly to the st2205 camlib,
to enable support for this new type of st2205 picture frames.
git-svn-id: https://svn.code.sf.net/p/gphoto/code/trunk/libgphoto2@15102 67ed7778-7388-44ab-90cf-0a291f65f57c
3) use the fact that realloc() is defined to simply malloc if the
first param is NULL, no need to manually distinguish between first and
later allocations.
git-svn-id: https://svn.code.sf.net/p/gphoto/code/trunk/libgphoto2@15098 67ed7778-7388-44ab-90cf-0a291f65f57c
here is a patch for (mostly) consistent usage of a generalized C_MEM
macro for checking the return values of memory allocating functions,
i.e. malloc, calloc, realloc and strdup. It is the C_MEM from
libusb1.c, moved to gphoto2-port-log.h.
git-svn-id: https://svn.code.sf.net/p/gphoto/code/trunk/libgphoto2@15096 67ed7778-7388-44ab-90cf-0a291f65f57c
