Bug 844999

Created attachment 601738 [details]
lsusb output for the webcam

Created attachment 601739 [details]
screenshot of the issue

This seems like it's probably libv4l component... but I'm not 100% sure.

Could you please try:
$ gst-launch-1.0 v4l2src device=/dev/video1 ! videoconvert ! videoscale !
autovideosink

If you get the same inverted image then this is indeed a v4l2 problem. I must also point out that cheese-3.4.x is too old. You should try with cheese-3.6.x and/or gstreamer 1.0.x.

(In reply to comment #4)
> Could you please try:
> $ gst-launch-1.0 v4l2src device=/dev/video1 ! videoconvert ! videoscale !
> autovideosink
> 
> If you get the same inverted image then this is indeed a v4l2 problem. I
> must also point out that cheese-3.4.x is too old. You should try with
> cheese-3.6.x and/or gstreamer 1.0.x.

Re-tested on F18 via gst-launch-0.10:
(Cheese 3.6.1; gst-launch-0.10 version 0.10.36)
Had to take videoconvert out of the pipe bacause: `WARNING: erroneous pipeline: no element "videoconvert"`
Bug was still present, so I guess you can change component to gstreamer.

(In reply to comment #5)
> Re-tested on F18 via gst-launch-0.10:
> (Cheese 3.6.1; gst-launch-0.10 version 0.10.36)

RHEL7 will be using GStreamer 1.0.x, not 0.10.x. F18's cheese is built against 1.0: rpm --requires -q cheese | grep libgstreamer

> Had to take videoconvert out of the pipe bacause: `WARNING: erroneous
> pipeline: no element "videoconvert"`

That is because the videoconvert element does not exist in 0.10.x. As far as I know, its counterpart in 0.10.x is ffmpegcolorspace.

Reassigning to gstreamer1-plugins-good because that is where the v4l2src is.

Could you please try with GStreamer 1.0:

$ GST_DEBUG=*v4l*:8 gst-launch-1.0 v4l2src ! videoconvert ! videoscale ! autovideosink 2>debug.log 

Then compress and attach debug.log here?

I'm pretty sure this is something that needs a tweak in libv4l2.

Yep this probably needs a libv4l2 upside-down webcam table entry (a table which is mostly filled with Asus models). 

Vasiliy,

Can you please do:

lsusb > lsusb.log
sudo dmidecode > dmi.log

And attach both logfiles here ?

Thanks,

Hans

Created attachment 861644 [details]
lsusb

Created attachment 861645 [details]
dmidecode

Vasiliy,

When is the last time you tried this ? This should just work with recent RHEL-7 snapshots and / or a recent Fedora. Can you give this another try?

Thanks & Regards,

Hans

This bug is still present in RHEL-7.0-20140210.0

Hi,

(In reply to Vasiliy Sharapov from comment #17)
> This bug is still present in RHEL-7.0-20140210.0

Hmm, perhaps your laptop is a false positive, and is getting flipped while it should not be flipped.

Can you try doing the following from a terminal:

LIBV4LCONTROL_FLAGS=0 cheese

And while at it, if the above does not help, can you also also try:

LIBV4LCONTROL_FLAGS=3 cheese

Thanks,

Hans

Ok, so Vasiliy gave me remote access to the machine and this is indeed a false positive of the upside-down cam detection in libv4l.

I need to think a bit about how to best fix this, moving to assigned.

Hi Vasiliy,

just to double check: This webcam is built into the laptop itself, correct?

(If yes, this bug answers my question if ASUS managed to built in a single webcam in the correct orientation :)

Thanks,
Gregor

I downloaded some webcam drivers for the F3Sc model from the ASUS website. I hoped that they use some DMI or ACPI bits to flag models with upside down webcams. But instead they copy the webcam driver(s) for every model and alter the flip and mirror bits in the driver inf file. What a mess!

The driver for the webcam owned by Vasiliy had the flip and mirror bits set to 0 in the .inf file. Some other cameras for the same model had both set to 1. Some other models with the same camera had the bits turned on.

Thus excluding the F3Sc from the upside-down table wouldn't be enough. So I decided to include a false-positive (aka. correctly orientated table) that is consulted, too.

Attached you'll find a proposal for a false-positive table. Hans, could you please review it? I'll try to come up with a unit test for the upside down table later.

Thanks,
Gregor

Created attachment 869598 [details]
Patch to add false positive table

Hi Gregor,

Thanks for working on this. I was planning on writing a fix for this myself, but I don't mind you beating me to it :)

I was thinking along the same lines as you are (add a list of known false-positives), only I was planning to re-use the existing v4lcontrol_flags table. Have you considered that?

My idea is to have a line for false positives inside the v4lcontrol_flags table with flags == 0, and to
modify v4lcontrol_get_flags_from_db to do the more specific (no wildcards) v4lcontrol_flags check first, and if that matches return from v4lcontrol_get_flags_from_db (instead of the current break.

Looking at this now, I think this should be really easy. I'll attach a quick and dirty (and untested) version of what I've in mind.

Regards,

Hans

Created attachment 869625 [details]
PATCH 1/2: libv4lcontrol: Check control_flags before doing wildcard  maching on upside_down

Created attachment 869626 [details]
Patch 2/2: libv4lcontrol: Add Asus F3Sc with 04f2:b012 cam as upside  down false positive

Hi,

I considered using the v4lcontrol_flags, too. The downside I saw is that no globbing is possible and the DMI values need to be whitespace correct.

But your patch looks much more sane than my one. I will test it, push it into the git repo, and will release a new stable v4l-utils version. This will happen during the next week.

Thanks,
Gregor

Vasiliy,

I've just done a brew scratch build with the patches we plan to merge upstream to get this fixed:
http://brewweb.devel.redhat.com/brew/taskinfo?taskID=7186372

Can you please install the libv4l packages from that build on the laptop, and see if they resolve the upside down issue ?

Thanks,

Hans

No response to need-info for 3 months, closing (the fix original developed here is upstream now).