Disable --auto-rotate in feh builds compiled wiht Imlib2 1.7.5+

Imlib2 v1.7.5 introduces automatic (and transparent) orientation adjustment
based on EXIF orientation tags. This makes feh's --auto-rotate function
both superfluous and erroneous: It doesn't know about Imlib2's adjustments,
so it rotates an image which is already correctly oriented, leading to
incorrect orientation.

I am not aware of a simple run-time check for detecting whethen running
Imlib2 < 1.7.5 or ≥ 1.7.5. For now, feh disables --auto-rotate entirely when
compiled on a system with Imlib2 1.7.5+ and outputs a warning when the
option is used.

Rationale: The Imlib2 version available at run-time should in most cases be
at least as recent as the Imlib2 version used at compile-time. So, while there
may be cases where feh was compiled with Imlib2 1.7.4 and exhibits erroneous
auto-rotate behaviour on an Imlib2 1.7.5 system, the inverse case
(a feh with disabled auto-rotate support running on Imlib2 1.7.4) should be
sufficiently rare. If it does occur, it can be remedied by compiling feh
from source locally.

Possible caveat: Imlib2 only adjusts for EXIF orientation when loading JPEG
and TIFF images. If there are additional EXIF-aware file formats supported by
feh, but not Imlib2, they lose auto-rotate support.

Reference: GitHub issue #642

1 files changed, 2 insertions, 1 deletions

diff --git a/src/imlib.c b/src/imlib.c
index add88d6..c42c4a4 100644
--- a/src/imlib.c
+++ b/src/imlib.c
@@ -462,8 +462,9 @@ int feh_load_image(Imlib_Image * im, feh_file * file)
 	if (file->ed) {
 		ExifByteOrder byteOrder = exif_data_get_byte_order(file->ed);
 		ExifEntry *exifEntry = exif_data_get_entry(file->ed, EXIF_TAG_ORIENTATION);
-		if (exifEntry && opt.auto_rotate)
+		if (exifEntry && opt.auto_rotate) {
 			orientation = exif_get_short(exifEntry->data, byteOrder);
+		}
 	}
 
 	if (orientation == 2)