Skip to contentSkip to conversation

RFC: adding a flag to indicate a webcam sensor is installed upside down

DISCUSSION Hans de Goede 5 participants 8 messages Aug 7, 2008 – Oct 21, 2008 Media (V4L/DVB)

lore
Share & tools
lore
#0 lore raw

Hi all,

I have this Philips SPC 200NC webcam, which has its sensor installed upside down and the sensor does not seem to support flipping the image. So I believe the windows drivers fix this little problem in software.

I would like to add a flag somewhere to indicate this to userspace (and then add flipping code to libv4l).

I think the best place for this would the flags field of the v4l2_fmtdesc struct. Any other ideas / objections to this?

Regards,

Hans

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

#1 lore raw
Quoted 11 lines · Hans de Goede

Hi all,

I have this Philips SPC 200NC webcam, which has its sensor installed upside down and the sensor does not seem to support flipping the image. So I believe the windows drivers fix this little problem in software.

I would like to add a flag somewhere to indicate this to userspace (and then add flipping code to libv4l).

I think the best place for this would the flags field of the v4l2_fmtdesc struct. Any other ideas / objections to this?

More often than sensors being mounted upside down in a webcam, what I've noticed frequently is webcam modules being mounted upside down in a laptop screen. There is no way that I'm aware of to check the module orientation based on the USB descriptors only. We will need a pure userspace solution.

Best regards,

Laurent Pinchart

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

#2 lore raw
Quoted 12 lines · Laurent Pinchart
Quoted 8 lines · Hans de Goede

Hi all,

I have this Philips SPC 200NC webcam, which has its sensor installed upside down and the sensor does not seem to support flipping the image. So I believe the windows drivers fix this little problem in software.

I would like to add a flag somewhere to indicate this to userspace (and then add flipping code to libv4l).

I think the best place for this would the flags field of the v4l2_fmtdesc struct. Any other ideas / objections to this?

More often than sensors being mounted upside down in a webcam, what I've noticed frequently is webcam modules being mounted upside down in a laptop screen. There is no way that I'm aware of to check the module orientation based on the USB descriptors only. We will need a pure userspace solution.

Interesting, still in my case it can be told from just the usb id (philips luckily uses its own id's instead of generic id's). So I think in cases were we can tell it at the kernel level we should set a flag somewhere (and I believe the flags field of the v4l2_fmtdesc is the best place) to share this knowledge with userspace.

Then for laptops we will need a detection mechanism probably based on DMI strings (I feel hal is going to play a role here) and then check for flipx and y v4l2_ctrl's and if those are not present use software flipping (which I'm going to implement today for my philips cam).

Hmm, thinking more about the laptop problem, ideally hal would just do the v4l-ctrl calls itself, so that this happens only once (on plugin) and users can later override this. And then we would need some kinda hal boolean which libv4l can query called something like "needs software flip" for the other cases.

Regards,

Hans

p.s.

If someone can ship me a laptop which an upside down mounted cam I'll happily work on this issue :)

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

#3 lore raw
In reply to Laurent Pinchart
Quoted 7 lines · Laurent Pinchart
Quoted 6 lines · Hans de Goede

Hi all,

I have this Philips SPC 200NC webcam, which has its sensor installed upside down and the sensor does not seem to support flipping the image. So I believe the windows drivers fix this little problem in software.

Quoted 7 lines
Quoted 5 lines

I would like to add a flag somewhere to indicate this to userspace (and then add flipping code to libv4l).

I think the best place for this would the flags field of the v4l2_fmtdesc struct. Any other ideas / objections to this?

More often than sensors being mounted upside down in a webcam, what I've noticed frequently is webcam modules being mounted upside down in a laptop screen. There is no way that I'm aware of to check the module orientation based on the USB descriptors only. We will need a pure userspace solution.

Agree.

Having a horizontal or vertical inversion may exist in any webcam (and tuner?), and may be the fact of wire inversion when assembling the device. So, having a flag in the driver could not work with hardware error.

If the sensor (or bridge?) may do H or V flip, we are done. If not, this may be done by software, but in the userspace, i.e. at decoding time.

What I propose is to add a check of the control commands V4L2_CID_HFLIP and V4L2_CID_VFLIP in the v4l library: if the driver does not have these controls, the library silenctly adds them and handles their requests. Then, at frame decoding time, the hflip and vflip may be given to the decoding functions.

How do you feel it, Hans?

Signature · 8 lines
Ken ar c'hentañ |             ** Breizh ha Linux atav! **
Jef             |               http://moinejf.free.fr/


--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
#4 lore raw
Quoted 32 lines · On Friday 08 August 2008 11:10:36 Jean-Francois Moine wrote:
Quoted 11 lines · Laurent Pinchart
Quoted 10 lines · Hans de Goede

Hi all,

I have this Philips SPC 200NC webcam, which has its sensor installed upside down and the sensor does not seem to support flipping the image. So I believe the windows drivers fix this little problem in software.

I would like to add a flag somewhere to indicate this to userspace (and then add flipping code to libv4l).

Quoted 8 lines
Quoted 2 lines

I think the best place for this would the flags field of the v4l2_fmtdesc struct. Any other ideas / objections to this?

More often than sensors being mounted upside down in a webcam, what I've noticed frequently is webcam modules being mounted upside down in a laptop screen. There is no way that I'm aware of to check the module orientation based on the USB descriptors only. We will need a pure userspace solution.

Agree.

Having a horizontal or vertical inversion may exist in any webcam (and tuner?), and may be the fact of wire inversion when assembling the device. So, having a flag in the driver could not work with hardware error.

If the sensor (or bridge?) may do H or V flip, we are done. If not, this may be done by software, but in the userspace, i.e. at decoding time.

Quoted 7 lines

What I propose is to add a check of the control commands V4L2_CID_HFLIP and V4L2_CID_VFLIP in the v4l library: if the driver does not have these controls, the library silenctly adds them and handles their requests. Then, at frame decoding time, the hflip and vflip may be given to the decoding functions.

How do you feel it, Hans?

I'm a different Hans :-), but I was thinking along the same lines. Having the v4l lib implement HFLIP/VFLIP if the driver doesn't seems like a good idea.

I also think that the UPSIDEDOWN flag doesn't belong to v4l2_fmtdesc since this is a global property, not specific to a format. I would suggest adding it to v4l2_capability instead:
V4L2_CAP_SENSOR_UPSIDE_DOWN. It should only be set if you know that the sensor is always upside down for that specific device and if there is no VFLIP capability (because if there is, then you can VFLIP by default for that device).

Regards,

Hans

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

#5 lore raw
Quoted 37 lines · Hans Verkuil
Quoted 36 lines · On Friday 08 August 2008 11:10:36 Jean-Francois Moine wrote:
Quoted 11 lines · Laurent Pinchart
Quoted 10 lines · Hans de Goede

Hi all,

I have this Philips SPC 200NC webcam, which has its sensor installed upside down and the sensor does not seem to support flipping the image. So I believe the windows drivers fix this little problem in software.

I would like to add a flag somewhere to indicate this to userspace (and then add flipping code to libv4l).

Quoted 7 lines
Quoted 2 lines

I think the best place for this would the flags field of the v4l2_fmtdesc struct. Any other ideas / objections to this?

More often than sensors being mounted upside down in a webcam, what I've noticed frequently is webcam modules being mounted upside down in a laptop screen. There is no way that I'm aware of to check the module orientation based on the USB descriptors only. We will need a pure userspace solution.

Agree.

Having a horizontal or vertical inversion may exist in any webcam (and tuner?), and may be the fact of wire inversion when assembling the device. So, having a flag in the driver could not work with hardware error.

If the sensor (or bridge?) may do H or V flip, we are done. If not, this may be done by software, but in the userspace, i.e. at decoding time.

What I propose is to add a check of the control commands V4L2_CID_HFLIP and V4L2_CID_VFLIP in the v4l library: if the driver does not have these controls, the library silenctly adds them and handles their requests. Then, at frame decoding time, the hflip and vflip may be given to the decoding functions.

Quoted 6 lines
Quoted 1 line

How do you feel it, Hans?

I'm a different Hans :-), but I was thinking along the same lines. Having the v4l lib implement HFLIP/VFLIP if the driver doesn't seems like a good idea.

I also think that the UPSIDEDOWN flag doesn't belong to v4l2_fmtdesc since this is a global property, not specific to a format. I would suggest adding it to v4l2_capability instead: V4L2_CAP_SENSOR_UPSIDE_DOWN. It should only be set if you know that the sensor is always upside down for that specific device and if there is no VFLIP capability (because if there is, then you can VFLIP by default for that device).

I agree that this is a per device thing, and that the flag thus should be moved to v4l2_capability. I'll redo a new patch against the gspca zc3xx driver with the flag moved to v4l2_capability.

About adding fake controls for HFLIP VFLIP to libv4l for devices which don't do this natively. This might be good to have, but my current patch for the upside down issue only supports. 180 degree rotation so, both vflip and hflip in one go.

Adding support for doing just vflip or just hflip is possible, but will take some time.

Also faking v4l2 controls currently is not done yet in libv4l, so doing this requires adding some infrastructure. All doable, but not at the top of my todo list at the moment.

As I see it there are 3 kind of upsidedown problems:

1) The sensor is upside down, and we can easily detect in the driver (by
usb id for example) and the driver does not support vflip and/or
hflip in the hardware. Solution: set a capability flag indicating this (and then in libv4l flip the image back in software, I've already written support for this). (Note when h and vflip are supported the driver should invert the meaning of the ctrl's so that the image ends up the right way up).

2) The sensor is upside down, and we can not easily detect this in the driver, but we can detect it in userspace. For example a sensor mounted upside down in the screen bevel of a laptop, which we can detect be determining the model of laptop from dmi strings as hal already does for things like setting up bindings of special keyb keys and for enabling suspend / resume problem workarounds.

Proposed solution: Give userspace (hal) a way to tell the kernel that the sensor is upside down, I'm thinking about a sysfs file for each video device here myself. and then let the kernel behave as scenario 1.

3) There is no way to tell the sensor is upside down. Proposed solution write a videodev preferences gui, where this can be indicated and then use the sysfs file mentioned in 2) to tell the kernel about the sensor being upside down. Note that currently no practical examples of this version of the problem are known.

I'm currently focussing on 1) as I actually have a cam which has its sensor upside down and has a unique device id. I'll submit a new patch against gspca adding a capability flag to indicate the image is upside down and adjust my libv4l patches to check for this flag and do flipping in sw when its set.

When this is in place adding a sysfs entry which allows userspace to set this flag should be easy.

Regards,

Hans

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

#6 lore raw
Quoted 10 lines · Hans de Goede

I agree that this is a per device thing, and that the flag thus should be moved to v4l2_capability. I'll redo a new patch against the gspca zc3xx driver with the flag moved to v4l2_capability.

About adding fake controls for HFLIP VFLIP to libv4l for devices which don't do this natively. This might be good to have, but my current patch for the upside down issue only supports. 180 degree rotation so, both vflip and hflip in one go.

you're referring flipping in hardware above right?

Quoted 2 lines

Adding support for doing just vflip or just hflip is possible, but will take some time.

Any update on this.

Personally I'm using a 0402:5606 webcam with the latest uvcvideo.ko There is a firmware update available for the webcam to flip the image, so I'm presuming that is just changing the appropriate setting to tell the hardware to flip the image.

There is no mention of *FLIP* capability in the uvcvideo driver at all. Is there a standard way to get/set that in the camera?

Quoted 3 lines

Also faking v4l2 controls currently is not done yet in libv4l, so doing this requires adding some infrastructure. All doable, but not at the top of my todo list at the moment.

So there is no software support yet.

cheers,
Pádraig.

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

#7 lore raw

Hi,

Quoted 16 lines · Pádraig Brady
Quoted 9 lines · Hans de Goede

I agree that this is a per device thing, and that the flag thus should be moved to v4l2_capability. I'll redo a new patch against the gspca zc3xx driver with the flag moved to v4l2_capability.

About adding fake controls for HFLIP VFLIP to libv4l for devices which don't do this natively. This might be good to have, but my current patch for the upside down issue only supports. 180 degree rotation so, both vflip and hflip in one go.

you're referring flipping in hardware above right?

Quoted 2 lines

Adding support for doing just vflip or just hflip is possible, but will take some time.

Quoted 6 lines

Any update on this.

Personally I'm using a 0402:5606 webcam with the latest uvcvideo.ko There is a firmware update available for the webcam to flip the image, so I'm presuming that is just changing the appropriate setting to tell the hardware to flip the image.

Most image sensors support vertical and horizontal flipping (or at least image rotation). So it's really a matter of setting the image sensor parameters correctly.

Quoted 2 lines

There is no mention of *FLIP* capability in the uvcvideo driver at all. Is there a standard way to get/set that in the camera?

Unfortunately the upside-down cameras don't export any hflip/vflip control, so there's no (known) way to control image rotation from the host.

Quoted 5 lines
Quoted 3 lines

Also faking v4l2 controls currently is not done yet in libv4l, so doing this requires adding some infrastructure. All doable, but not at the top of my todo list at the moment.

So there is no software support yet.

Best regards,

Laurent Pinchart

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list