Re: [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around
On Thu, Feb 14, 2013 at 8:12 AM, Hans Verkuil hverk...@xs4all.nl wrote: Arvydas, can you please test this? I'd like to do a git pull tomorrow and I'd like to know if the upside-down changes are now OK. Thanks, Hi Hans Everything is working fine now - dmesg is clean, LED lights on and off when needed, viewport angle is correct. Thanks for the fixes. Arvydas -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around
On Tue February 12 2013 09:28:55 Hans Verkuil wrote: On Mon February 11 2013 16:32:58 Arvydas Sidorenko wrote: On Mon, Feb 11, 2013 at 2:21 PM, Hans Verkuil hverk...@xs4all.nl wrote: That doesn't make sense either. Arvydas, it worked fine for you before, right? That is, if you use e.g. v3.8-rc7 then your picture is the right side up. It is upside down using any v3.7.x or v3.8-rc7. I didn't pay attention in the older versions, but I am aware of this issue since pre-v3. On Mon, Feb 11, 2013 at 2:41 PM, Hans de Goede hdego...@redhat.com wrote: Arvydas, can you please run sudo dmidecode dmi.log, and send me or Hans V. the generated dmi.log file? Then we can add your laptop to the upside-down model list. $ sudo dmidecode Thanks! I've updated my stkwebcam git branch (note: it was rebased, so you can't just do a git pull). If you can do a final test? Arvydas, can you please test this? I'd like to do a git pull tomorrow and I'd like to know if the upside-down changes are now OK. Thanks, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around
On Mon February 11 2013 16:32:58 Arvydas Sidorenko wrote: On Mon, Feb 11, 2013 at 2:21 PM, Hans Verkuil hverk...@xs4all.nl wrote: That doesn't make sense either. Arvydas, it worked fine for you before, right? That is, if you use e.g. v3.8-rc7 then your picture is the right side up. It is upside down using any v3.7.x or v3.8-rc7. I didn't pay attention in the older versions, but I am aware of this issue since pre-v3. On Mon, Feb 11, 2013 at 2:41 PM, Hans de Goede hdego...@redhat.com wrote: Arvydas, can you please run sudo dmidecode dmi.log, and send me or Hans V. the generated dmi.log file? Then we can add your laptop to the upside-down model list. $ sudo dmidecode Thanks! I've updated my stkwebcam git branch (note: it was rebased, so you can't just do a git pull). If you can do a final test? Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around
On Sun February 10 2013 18:52:42 Hans Verkuil wrote:
From: Hans Verkuil hans.verk...@cisco.com
This resulted in an upside-down picture.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Tested-by: Arvydas Sidorenko asi...@gmail.com
As mentioned in this thread, this patch was wrong. It's now replaced by the
version below which includes the background information given by Hans de Goede.
Regards,
Hans
[PATCH 01/12] stk-webcam: add ASUS F3JC to upside-down list.
And add an extensive comment relating the history of the upside-down
handling in this driver.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Thanks-to: Hans de Goede hdego...@redhat.com
Thanks-to: Arvydas Sidorenko asi...@gmail.com
---
drivers/media/usb/stkwebcam/stk-webcam.c | 40 +-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/drivers/media/usb/stkwebcam/stk-webcam.c
b/drivers/media/usb/stkwebcam/stk-webcam.c
index 4cbab08..b2a5ee4 100644
--- a/drivers/media/usb/stkwebcam/stk-webcam.c
+++ b/drivers/media/usb/stkwebcam/stk-webcam.c
@@ -63,7 +63,39 @@ static struct usb_device_id stkwebcam_table[] = {
};
MODULE_DEVICE_TABLE(usb, stkwebcam_table);
-/* The stk webcam laptop module is mounted upside down in some laptops :( */
+/*
+ * The stk webcam laptop module is mounted upside down in some laptops :(
+ *
+ * Some background information (thanks to Hans de Goede for providing this):
+ *
+ * 1) Once upon a time the stkwebcam driver was written
+ *
+ * 2) The webcam in question was used mostly in Asus laptop models, including
+ * the laptop of the original author of the driver, and in these models, in
+ * typical Asus fashion (see the long long list for uvc cams inside v4l-utils),
+ * they mounted the webcam-module the wrong way up. So the hflip and vflip
+ * module options were given a default value of 1 (the correct value for
+ * upside down mounted models)
+ *
+ * 3) Years later I got a bug report from a user with a laptop with stkwebcam,
+ * where the module was actually mounted the right way up, and thus showed
+ * upside down under Linux. So now I was facing the choice of 2 options:
+ *
+ * a) Add a not-upside-down list to stkwebcam, which overrules the default.
+ *
+ * b) Do it like all the other drivers do, and make the default right for
+ *cams mounted the proper way and add an upside-down model list, with
+ *models where we need to flip-by-default.
+ *
+ * Despite knowing that going b) would cause a period of pain where we were
+ * building the table I opted to go for option b), since a) is just too ugly,
+ * and worse different from how every other driver does it leading to
+ * confusion in the long run. This change was made in kernel 3.6.
+ *
+ * So for any user report about upside-down images since kernel 3.6 ask them
+ * to provide the output of 'sudo dmidecode' so the laptop can be added in
+ * the table below.
+ */
static const struct dmi_system_id stk_upside_down_dmi_table[] = {
{
.ident = ASUS G1,
@@ -71,6 +103,12 @@ static const struct dmi_system_id
stk_upside_down_dmi_table[] = {
DMI_MATCH(DMI_SYS_VENDOR, ASUSTeK Computer Inc.),
DMI_MATCH(DMI_PRODUCT_NAME, G1)
}
+ }, {
+ .ident = ASUS F3JC,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, ASUSTeK Computer Inc.),
+ DMI_MATCH(DMI_PRODUCT_NAME, F3JC)
+ }
},
{}
};
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around
Hi, Subject: stk-webcam: the initial hflip and vflip setup was the wrong way around No it is not. On 02/10/2013 06:52 PM, Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com This resulted in an upside-down picture. No it does not, the laptop having an upside down mounted camera and not being in the dmi-table is what causes an upside down picture. For a non upside down camera (so no dmi-match) hflip and vflip should be 0. The fix for the upside-down-ness Arvydas Sidorenko reported would be to add his laptop to the upside down table. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around
Hi, On 02/11/2013 02:21 PM, Hans Verkuil wrote: On Mon February 11 2013 14:08:44 Hans de Goede wrote: Hi, Subject: stk-webcam: the initial hflip and vflip setup was the wrong way around No it is not. You are right, that patch makes no sense. It was a long day :-) On 02/10/2013 06:52 PM, Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com This resulted in an upside-down picture. No it does not, the laptop having an upside down mounted camera and not being in the dmi-table is what causes an upside down picture. For a non upside down camera (so no dmi-match) hflip and vflip should be 0. The fix for the upside-down-ness Arvydas Sidorenko reported would be to add his laptop to the upside down table. That doesn't make sense either. Arvydas, it worked fine for you before, right? Yes, it probably worked before, but not with... That is, if you use e.g. v3.8-rc7 then your picture is the right side up. 3.8 will show it upside down for Arvydas The story goes likes this: 1) Once upon a time the stkwebcam driver was written 2) The webcam in question was used mostly in Asus laptop models, including the laptop of the original author of the driver, and in these models, in typical Asus fashion (see the long long list for uvc cams inside v4l-utils), they mounted the webcam-module the wrong way up. So the hflip and vflip module options were given a default value of 1 (the correct value for upside down mounted models) 3) Years later I got a bug report from a user with a laptop with stkwebcam, where the module was actually mounted the right way up, and thus showed upside down under Linux. So now I was facing the choice of 2 options: a) Add a not-upside-down list to stkwebcam, which overrules the default b) Do it like all the other drivers do, and make the default right for cams mounted the proper way and add an upside-down model list, with models where we need to flip-by-default. Despite knowing that going b) would cause a period of pain where we were building the table (ie what we're discussing now) I opted to go for option b), since a) is just too ugly, and worse different from how every other driver does it leading to confusion in the long run. IOW this is entirely my fault, and I take full responsibility for it. Arvydas, can you please run sudo dmidecode dmi.log, and send me or Hans V. the generated dmi.log file? Then we can add your laptop to the upside-down model list. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around
On Mon February 11 2013 14:41:08 Hans de Goede wrote: Hi, On 02/11/2013 02:21 PM, Hans Verkuil wrote: On Mon February 11 2013 14:08:44 Hans de Goede wrote: Hi, Subject: stk-webcam: the initial hflip and vflip setup was the wrong way around No it is not. You are right, that patch makes no sense. It was a long day :-) On 02/10/2013 06:52 PM, Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com This resulted in an upside-down picture. No it does not, the laptop having an upside down mounted camera and not being in the dmi-table is what causes an upside down picture. For a non upside down camera (so no dmi-match) hflip and vflip should be 0. The fix for the upside-down-ness Arvydas Sidorenko reported would be to add his laptop to the upside down table. That doesn't make sense either. Arvydas, it worked fine for you before, right? Yes, it probably worked before, but not with... That is, if you use e.g. v3.8-rc7 then your picture is the right side up. 3.8 will show it upside down for Arvydas The story goes likes this: 1) Once upon a time the stkwebcam driver was written 2) The webcam in question was used mostly in Asus laptop models, including the laptop of the original author of the driver, and in these models, in typical Asus fashion (see the long long list for uvc cams inside v4l-utils), they mounted the webcam-module the wrong way up. So the hflip and vflip module options were given a default value of 1 (the correct value for upside down mounted models) 3) Years later I got a bug report from a user with a laptop with stkwebcam, where the module was actually mounted the right way up, and thus showed upside down under Linux. So now I was facing the choice of 2 options: a) Add a not-upside-down list to stkwebcam, which overrules the default b) Do it like all the other drivers do, and make the default right for cams mounted the proper way and add an upside-down model list, with models where we need to flip-by-default. Despite knowing that going b) would cause a period of pain where we were building the table (ie what we're discussing now) I opted to go for option b), since a) is just too ugly, and worse different from how every other driver does it leading to confusion in the long run. IOW this is entirely my fault, and I take full responsibility for it. Ah, OK. Now it makes sense. I wasn't aware of this history and it (clearly) confused me greatly. Can you perhaps provide me with a patch that adds some comments to the source explaining this. And in particular with which kernel this change took place? The next time some poor sod (e.g. me) has to work on this the comments should explain this history. Arvydas, can you please run sudo dmidecode dmi.log, and send me or Hans V. the generated dmi.log file? Then we can add your laptop to the upside-down model list. When I have this information I'll update my patch series and ask Arvydas to test again. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around
Hi, On 02/11/2013 02:51 PM, Hans Verkuil wrote: On Mon February 11 2013 14:41:08 Hans de Goede wrote: Hi, On 02/11/2013 02:21 PM, Hans Verkuil wrote: On Mon February 11 2013 14:08:44 Hans de Goede wrote: Hi, Subject: stk-webcam: the initial hflip and vflip setup was the wrong way around No it is not. You are right, that patch makes no sense. It was a long day :-) On 02/10/2013 06:52 PM, Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com This resulted in an upside-down picture. No it does not, the laptop having an upside down mounted camera and not being in the dmi-table is what causes an upside down picture. For a non upside down camera (so no dmi-match) hflip and vflip should be 0. The fix for the upside-down-ness Arvydas Sidorenko reported would be to add his laptop to the upside down table. That doesn't make sense either. Arvydas, it worked fine for you before, right? Yes, it probably worked before, but not with... That is, if you use e.g. v3.8-rc7 then your picture is the right side up. 3.8 will show it upside down for Arvydas The story goes likes this: 1) Once upon a time the stkwebcam driver was written 2) The webcam in question was used mostly in Asus laptop models, including the laptop of the original author of the driver, and in these models, in typical Asus fashion (see the long long list for uvc cams inside v4l-utils), they mounted the webcam-module the wrong way up. So the hflip and vflip module options were given a default value of 1 (the correct value for upside down mounted models) 3) Years later I got a bug report from a user with a laptop with stkwebcam, where the module was actually mounted the right way up, and thus showed upside down under Linux. So now I was facing the choice of 2 options: a) Add a not-upside-down list to stkwebcam, which overrules the default b) Do it like all the other drivers do, and make the default right for cams mounted the proper way and add an upside-down model list, with models where we need to flip-by-default. Despite knowing that going b) would cause a period of pain where we were building the table (ie what we're discussing now) I opted to go for option b), since a) is just too ugly, and worse different from how every other driver does it leading to confusion in the long run. IOW this is entirely my fault, and I take full responsibility for it. Ah, OK. Now it makes sense. I wasn't aware of this history and it (clearly) confused me greatly. Can you perhaps provide me with a patch that adds some comments to the source explaining this. And in particular with which kernel this change took place? Feel free to copy my 1) - 3) From above to a comment, step 3 landed in kernel 3.6 (you doing it seems better then me doing a patch conflicting with your patchset) The next time some poor sod (e.g. me) has to work on this the comments should explain this history. Ack. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around
I think the driver is not up to standard: look at the error messages. And there are a lot of to do because of lack of documentation. On Mon, Feb 11, 2013 at 4:55 PM, Hans de Goede hdego...@redhat.com wrote: Hi, On 02/11/2013 02:51 PM, Hans Verkuil wrote: On Mon February 11 2013 14:41:08 Hans de Goede wrote: Hi, On 02/11/2013 02:21 PM, Hans Verkuil wrote: On Mon February 11 2013 14:08:44 Hans de Goede wrote: Hi, Subject: stk-webcam: the initial hflip and vflip setup was the wrong way around No it is not. You are right, that patch makes no sense. It was a long day :-) On 02/10/2013 06:52 PM, Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com This resulted in an upside-down picture. No it does not, the laptop having an upside down mounted camera and not being in the dmi-table is what causes an upside down picture. For a non upside down camera (so no dmi-match) hflip and vflip should be 0. The fix for the upside-down-ness Arvydas Sidorenko reported would be to add his laptop to the upside down table. That doesn't make sense either. Arvydas, it worked fine for you before, right? Yes, it probably worked before, but not with... That is, if you use e.g. v3.8-rc7 then your picture is the right side up. 3.8 will show it upside down for Arvydas The story goes likes this: 1) Once upon a time the stkwebcam driver was written 2) The webcam in question was used mostly in Asus laptop models, including the laptop of the original author of the driver, and in these models, in typical Asus fashion (see the long long list for uvc cams inside v4l-utils), they mounted the webcam-module the wrong way up. So the hflip and vflip module options were given a default value of 1 (the correct value for upside down mounted models) 3) Years later I got a bug report from a user with a laptop with stkwebcam, where the module was actually mounted the right way up, and thus showed upside down under Linux. So now I was facing the choice of 2 options: a) Add a not-upside-down list to stkwebcam, which overrules the default b) Do it like all the other drivers do, and make the default right for cams mounted the proper way and add an upside-down model list, with models where we need to flip-by-default. Despite knowing that going b) would cause a period of pain where we were building the table (ie what we're discussing now) I opted to go for option b), since a) is just too ugly, and worse different from how every other driver does it leading to confusion in the long run. IOW this is entirely my fault, and I take full responsibility for it. Ah, OK. Now it makes sense. I wasn't aware of this history and it (clearly) confused me greatly. Can you perhaps provide me with a patch that adds some comments to the source explaining this. And in particular with which kernel this change took place? Feel free to copy my 1) - 3) From above to a comment, step 3 landed in kernel 3.6 (you doing it seems better then me doing a patch conflicting with your patchset) The next time some poor sod (e.g. me) has to work on this the comments should explain this history. Ack. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around
On Mon, Feb 11, 2013 at 2:21 PM, Hans Verkuil hverk...@xs4all.nl wrote: That doesn't make sense either. Arvydas, it worked fine for you before, right? That is, if you use e.g. v3.8-rc7 then your picture is the right side up. It is upside down using any v3.7.x or v3.8-rc7. I didn't pay attention in the older versions, but I am aware of this issue since pre-v3. On Mon, Feb 11, 2013 at 2:41 PM, Hans de Goede hdego...@redhat.com wrote: Arvydas, can you please run sudo dmidecode dmi.log, and send me or Hans V. the generated dmi.log file? Then we can add your laptop to the upside-down model list. $ sudo dmidecode # dmidecode 2.11 SMBIOS 2.4 present. 37 structures occupying 1499 bytes. Table at 0x000E5020. Handle 0x, DMI type 0, 24 bytes BIOS Information Vendor: American Megatrends Inc. Version: 305 Release Date: 02/15/2007 Address: 0xF Runtime Size: 64 kB ROM Size: 512 kB Characteristics: ISA is supported PCI is supported PC Card (PCMCIA) is supported PNP is supported BIOS is upgradeable BIOS shadowing is allowed ESCD support is available Boot from CD is supported Selectable boot is supported EDD is supported 5.25/1.2 MB floppy services are supported (int 13h) 3.5/720 kB floppy services are supported (int 13h) 3.5/2.88 MB floppy services are supported (int 13h) Print screen service is supported (int 5h) 8042 keyboard services are supported (int 9h) Printer services are supported (int 17h) CGA/mono video services are supported (int 10h) ACPI is supported USB legacy is supported Smart battery is supported BIOS boot specification is supported Function key-initiated network boot is supported Targeted content distribution is supported BIOS Revision: 1.124 Firmware Revision: 168.153 Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: ASUSTeK Computer Inc. Product Name: F3JC Version: 1.0 Serial Number: SSN12345678901234567 UUID: F13181DB-43CD-9AAD-CE00-0018F338B599 Wake-up Type: Power Switch SKU Number: Family: Handle 0x0002, DMI type 2, 15 bytes Base Board Information Manufacturer: ASUSTeK Computer Inc. Product Name: F3JC Version: 1.0 Serial Number: BSN12345678901234567 Asset Tag: ATN12345678901234567 Features: Board is a hosting board Board requires at least one daughter board Board is replaceable Location In Chassis: MIDDLE Chassis Handle: 0x0003 Type: Motherboard Contained Object Handles: 0 Handle 0x0003, DMI type 3, 21 bytes Chassis Information Manufacturer: ASUSTeK Computer Inc. Type: Notebook Lock: Not Present Version: Serial Number: Asset Tag: Boot-up State: Safe Power Supply State: Safe Thermal State: Safe Security Status: None OEM Information: 0x Height: Unspecified Number Of Power Cords: 1 Contained Elements: 0 Handle 0x0004, DMI type 4, 35 bytes Processor Information Socket Designation: Socket 478 Type: Central Processor Family: Other Manufacturer: Intel ID: F6 06 00 00 FF FB EB BF Signature: Type 0, Family 6, Model 15, Stepping 6 Flags: FPU (Floating-point unit on-chip) VME (Virtual mode extension) DE (Debugging extension) PSE (Page size extension) TSC (Time stamp counter) MSR (Model specific registers) PAE (Physical address extension) MCE (Machine check exception) CX8 (CMPXCHG8 instruction supported) APIC (On-chip APIC hardware supported) SEP (Fast system call) MTRR (Memory type range registers) PGE (Page global enable) MCA (Machine check architecture) CMOV (Conditional move instruction supported) PAT (Page attribute table) PSE-36 (36-bit page size extension) CLFSH (CLFLUSH instruction supported) DS (Debug store) ACPI (ACPI supported) MMX (MMX technology supported) FXSR (FXSAVE and FXSTOR instructions supported) SSE (Streaming SIMD extensions) SSE2 (Streaming SIMD extensions 2) SS (Self-snoop) HTT (Multi-threading) TM (Thermal monitor supported)
[RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around
From: Hans Verkuil hans.verk...@cisco.com This resulted in an upside-down picture. Signed-off-by: Hans Verkuil hans.verk...@cisco.com Tested-by: Arvydas Sidorenko asi...@gmail.com --- drivers/media/usb/stkwebcam/stk-webcam.c |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/media/usb/stkwebcam/stk-webcam.c b/drivers/media/usb/stkwebcam/stk-webcam.c index 4cbab08..71ac307 100644 --- a/drivers/media/usb/stkwebcam/stk-webcam.c +++ b/drivers/media/usb/stkwebcam/stk-webcam.c @@ -1305,15 +1305,15 @@ static int stk_camera_probe(struct usb_interface *interface, if (hflip != -1) dev-vsettings.hflip = hflip; else if (dmi_check_system(stk_upside_down_dmi_table)) - dev-vsettings.hflip = 1; - else dev-vsettings.hflip = 0; + else + dev-vsettings.hflip = 1; if (vflip != -1) dev-vsettings.vflip = vflip; else if (dmi_check_system(stk_upside_down_dmi_table)) - dev-vsettings.vflip = 1; - else dev-vsettings.vflip = 0; + else + dev-vsettings.vflip = 1; dev-n_sbufs = 0; set_present(dev); -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
