From: Sergey Lebedev <lsa.uz@pm.me>
To: German Pablo Lindo <germanpapulindez@gmail.com>
Cc: Sakari Ailus <sakari.ailus@linux.intel.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Hans de Goede <hansg@kernel.org>,
Dan Scally <dan.scally@ideasonboard.com>,
linux-media@vger.kernel.org
Subject: Re: More details for Test [PATCH] media: ipu-bridge: the Surface Pro 11 rear sensor is mounted upside down
Date: Sun, 13 Sep 2026 19:24:47 +0000 [thread overview]
Message-ID: <20260913192442.53249-1-lsa.uz@pm.me> (raw)
In-Reply-To: <20260913185735.6607-1-germanpapulindez@gmail.com>
Thank you. That is the answer, and it settles the question.
You have given me three things today that I could not have got on my own: a
test on a second machine, the cause of the colour error, and now this. I am
grateful for all three, and the last one I had asked for because I could not
test it here.
Your result and my measurement agree, and each explains the other. libcamera
does not rotate the image, and your qcam result is the evidence of that on
0.7.2. I measured the same here on 0.5.0: with the patch loaded I asked for
rot0, and it answered "Camera configuration adjusted" and returned the same
frame, the same way up. The sensor has no flip control, so libcamera tells
the application it cannot do it and hands the picture over unturned.
So qcam is right to show it upside down. qcam uses libcamera directly. And
your idea about pipewire is very likely the answer for the other two:
Snapshot and Firefox receive the frame through pipewire, which reads the
rotation property and applies it.
That is a better outcome for the patch than I expected. The kernel now
reports the mounting truthfully, and the two programs most people use act on
it:
Gnome Snapshot correct, in the preview and in the saved file
Firefox correct
qcam not flipped, which is the expected behaviour
For the patch itself, no change is needed. Its commit message already says
that an application reading the property can rotate and one ignoring it will
not, and your three programs have now confirmed both halves of that on a
second machine. Your Tested-by applies to it unchanged.
A v2 would only make that paragraph concrete by naming the programs, and I do
not think that earns a respin on its own. If a version is needed for any other
reason, it goes in then and I carry your tag into it by hand. So there is
nothing outstanding from me here.
Sergey
next prev parent reply other threads:[~2026-09-13 19:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-13 15:35 [PATCH] media: ipu-bridge: the Surface Pro 11 rear sensor is mounted upside down Sergey Lebedev
2026-09-13 17:01 ` Test " German Pablo Lindo
2026-09-13 17:23 ` Sergey Lebedev
2026-09-13 18:57 ` More details for " German Pablo Lindo
2026-09-13 19:24 ` Sergey Lebedev [this message]
2026-09-17 11:52 ` Sakari Ailus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260913192442.53249-1-lsa.uz@pm.me \
--to=lsa.uz@pm.me \
--cc=dan.scally@ideasonboard.com \
--cc=germanpapulindez@gmail.com \
--cc=hansg@kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=sakari.ailus@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox