Weekend patches (March 20-22, 2009)

[Brian Johnson]

Alright here is a thread to post any patches to test this weekend.

I've attached my wo patches i've been working on to this message
1. adds support for USB suspend/resume
2. exposes webcam button presses via the linux evdev input system

Suspend/Resume support seems to work reasonably well on my own
machine, with me being able to open up mplayer suspend the machine and
when i resume mplayer is still delivering a valid video stream.

My second patch is is a combination of the two patches related to
webcam buttons in a previous post that i have combined into one as
well as modified my thread function to support suspend/resume. This
patch probably needs a bit of testing with different web cams that
have buttons. It should work ok as it is now, however i would like
some more information about which webcams are known to have buttons,
if there are any that have more then one and which bits in the general
purpose input registers(1005 and 1009) are set when a button is
pressed. You can find out that information using debugfs. Testing the
current button events cn be done using gizmod.

# sudo gizmod -g

Thsi will start gizmod in debug mode and you should see information
about BTN_0 - BTN_7 show up when pressing your webcam buttons

[Josua Grawitter]

> --~--~---------~--~----~------------~-------~--~----~
> Lets make microdia webcams plug'n play, (currently plug'n pray)
> To post to this group, send email to micr...@googlegroups.com
> Visit us online https://groups.google.com/group/microdia
> -~----------~----~----~----~------~----~------~--~---

About the buttons,
I couldn't get gizmod compiled and there seem to be no RPMs ou there. I will
try to do it with keytouch. BTW - can you explain that for-loop - I don't
quite get how it is supposed to work (the cams use different GPIOs, don't
they?)

GWater

[Brian Johnson]

The for loop makes several assumptions since i do not know exactly
which cameras have buttons, how many or which general purpose input
registers are used.

1. I assume all button presses show up on the lower 8 input regiseters
( bridge register 1005)
2. I assume that any bits set to 1 when camera is initialized are not
used as buttons. a unpressed button should have a value of 0
3. button presses are the only thing that effects the state of
registers that are 0 when camera is inited.


Given these assumptions i created a mask that is the inverse of the
initialized state of register 1005. This is used to only check bits
that may be used to generate button presses given my assumptions that
is all bits in 1005 that were zero after initialization. Then in the
thread loop I'm checking each of those bits to see if they are one or
zero and generate the appropriate press or release event for a button.
The linux input subsystem is smart enough not to actually generate a
new event if the state has not changed.

This way of doing things is not the most accurate but i believe it
should actually generate correct events for webcams with buttons and
not generate events for ones that do not have buttons. This is why as
part of testing this patch i hope people can supply information as to
how many buttons their cams have as well as what input registers they
use to signal button presses.

On Wed, Mar 18, 2009 at 5:30 PM, Josua Grawitter
<grew...@googlemail.com> wrote:
> Am Mittwoch 18 März 2009 22:22:49 schrieb Brian Johnson:
>> Alright here is a thread to post any patches to test this weekend.
>>
>> I've attached my wo patches i've been working on to this message
>> 1. adds support for USB suspend/resume
>> 2. exposes webcam button presses via the linux evdev input system
>>
>>
>> Suspend/Resume support seems to work reasonably well on my own
>> machine, with me being able to open up mplayer suspend the machine and
>> when i resume mplayer is still delivering a valid video stream.
>>
>> My second patch is is a combination of the two patches related to
>> webcam buttons in a previous post that i have combined into one as
>> well as modified my thread function to support suspend/resume. This
>> patch probably needs a bit of testing with different web cams that
>> have buttons. It should work ok as it is now, however i would like
>> some more information about which webcams are known to have buttons,
>> if there are any that have more then one and which bits in the general
>> purpose input registers(1005 and 1009) are set when a button is
>> pressed. You can find out that information using debugfs. Testing the
>> current button events cn be done using gizmod.
>>
>> # sudo gizmod -g
>>
>> Thsi will start gizmod in debug mode and you should see information
>> about BTN_0 - BTN_7 show up when pressing your webcam buttons
>>
>> >

[Pablo Castellano]

Nice job! This is the only thing I can say :)

--
Regards, Pablo.

[Brian Johnson]

Ok If noone has any issues with these patches i'm going to push them
when i get home later this this evening.

[Josua Grawitter]

> --~--~---------~--~----~------------~-------~--~----~
> Lets make microdia webcams plug'n play, (currently plug'n pray)
> To post to this group, send email to micr...@googlegroups.com
> Visit us online https://groups.google.com/group/microdia
> -~----------~----~----~----~------~----~------~--~---

Great. I hope to figure out my camera's problem with the saturation patches
this evening and when they are in it's time for final testing and kernel
submission.

GWater

[Brian Johnson]

Pushed

[Boris Borisov]

Brian
You are not push the patch for control of hie and saturation.

[Gray Water]

Your patch was not commited because it locked my computer up several times.

Luckily I hope to have found the cause:
1. set_optical_parameters() is very performance hungry - which is ok
   as long as it is called only once.
2. MPlayer always resets the video device ("just to make sure").
3. Our reset function calls set_optical_parameters() 4 times
   through wrapper functions:
   - contrast
   - brightness
   - hue
   - saturation
4. Together with the isoc_init in the usb subsystem, the buffer system
   initializing itself and mplayer loading libv4l in userspace my computer
   can't cope and locks up.

   Hopefully removing the wrappers as I suggested before will fix this.

   GWater

2009/3/25 Boris Borisov <lz1...@gmail.com>

[Brian Johnson]

It also wasn't committed due to not having the checkpatch.pl errors fixed yet.


Do you know what exactly is so performance hungry in regards to
set_optical_parameters?

Also how would removing the wrappers fix it from being called 4 times
you stil need to set each of those 4 items even without the wrappers
correct? though since all the wrappers do is call
set_optical_parameters they should probably be removed anyways.

2009/3/25 Gray Water <grew...@googlemail.com>:

[Boris Borisov]

As global the function is very simple just a bit operation and I not found hungry code.
Also strange situation is, if I set the parameters out of wrapper function and call set_optical.... then the parameters is not changed.
On current version present in git the set contrast is call 2 times. And that is reason for call 4 times if function for brightness, contrast. hue, saturation is one. Multiple calls is happened for mplayer 2 times and for kopette 8 times. Not for ekiga, skype, amsn.
I'm little bit confused.
Mplayer log
Mar 25 21:58:33 shemet sn9c20x: Contrast is set
Mar 25 21:58:33 shemet sn9c20x: Gama is set   
Mar 25 21:58:33 shemet sn9c20x: Sharpness is set
Mar 25 21:58:33 shemet sn9c20x: Red gain is set
Mar 25 21:58:33 shemet sn9c20x: Blue gain is set
Mar 25 21:58:33 shemet sn9c20x: Using yuv420 output format
Mar 25 21:58:33 shemet driver: '2-4:1.0': driver_bound: bound to device 'sn9c20x'
Mar 25 21:58:33 shemet bus: 'usb': really_probe: bound device 2-4:1.0 to driver sn9c20x
Mar 25 21:58:33 shemet usbcore: registered new interface driver sn9c20x
Mar 25 21:58:33 shemet sn9c20x: SN9C20x USB 2.0 Webcam Driver v2009.01 loaded


Mar 25 21:58:46 shemet sn9c20x: Contrast is set
Mar 25 21:58:46 shemet sn9c20x: Contrast is set
Mar 25 21:58:47 shemet device: 'usbdev2.4_ep81': device_unregister
Mar 25 21:58:47 shemet PM: Removing info for No Bus:usbdev2.4_ep81

Kopete log
Mar 25 22:47:48 shemet sn9c20x: Using yuv420 output format
Mar 25 22:47:48 shemet sn9c20x: Using yuv420 output format
Mar 25 22:47:48 shemet sn9c20x: Using raw output format
Mar 25 22:47:48 shemet sn9c20x: Using yuv420 output format
Mar 25 22:47:48 shemet sn9c20x: Contrast is set
Mar 25 22:47:48 shemet sn9c20x: Contrast is set
Mar 25 22:47:48 shemet sn9c20x: Gama is set
Mar 25 22:47:48 shemet sn9c20x: Contrast is set
Mar 25 22:47:48 shemet sn9c20x: Contrast is set
Mar 25 22:47:48 shemet sn9c20x: Gama is set
Mar 25 22:47:48 shemet sn9c20x: Contrast is set
Mar 25 22:47:48 shemet sn9c20x: Contrast is set
Mar 25 22:47:48 shemet sn9c20x: Using yuv420 output format
Mar 25 22:47:48 shemet sn9c20x: Contrast is set
Mar 25 22:47:48 shemet sn9c20x: Contrast is set

Brian Johnson wrote:

It also wasn't committed due to not having the checkpatch.pl errors fixed yet.


Do you know what exactly is so performance hungry in regards to
set_optical_parameters?

Also how would removing the wrappers fix it from being called 4 times
you stil need to set each of those 4 items even without the wrappers
correct? though since all the wrappers do is call
set_optical_parameters they should probably be removed anyways.

2009/3/25 Gray Water <grew...@googlemail.com>:
  

Your patch was not commited because it locked my computer up several times.

Luckily I hope to have found the cause:
1. set_optical_parameters() is very performance hungry - which is ok
љљ as long as it is called only once.
2. MPlayer always resets the video device ("just to make sure").
3. Our reset function calls set_optical_parameters() 4 times
љљ through wrapper functions:
љљ - contrast
љљ - brightness
љљ - hue
љљ - saturation
4. Together with the isoc_init in the usb subsystem, the buffer system
љљ initializing itself and mplayer loading libv4l in userspace my computer
љљ can't cope and locks up.

љљ Hopefully removing the wrappers as I suggested before will fix this.

љљ GWater


2009/3/25 Boris Borisov <lz1...@gmail.com>
    

[Gray Water]

Maybe there is a way we could find a compromise:
Brightness and contrast get their own functions back. optical_parameters just reads out the values for the affected registers. This way we can at  least reduce the number of times optical_parameters is executed.

Performance:
My assumption ("optical_parameters is perfrmance hungry") is based solely upn my experience uring the testing. I have no idea how the CPU's or the C languages internals work and can therefore not point the finger at a specific piece of code. Does typecasting involve a lot of calculation?

[Brian Johnson]

brightness and contrast really should be set at the same time since
all these controls use the color matrix its much easier to just
calculate the new amtrix values and set them all at once. Also i'm
really not sure what could be so performance hungry in this function
since its just doing array lookups and bit shifitng. I'm curious have
you tried disabling all the callbacks for the optical controls but
that saturation one and seeing if it still hangs?

[Boris Borisov]

Ok I try to increase performance with 30% and send again the patch
Brian Johnson wrote:

:


Your patch was not commited because it locked my computer up several
times.

Luckily I hope to have found the cause:
1. set_optical_parameters() is very performance hungry - which is ok
љљ as long as it is called only once.
2. MPlayer always resets the video device ("just to make sure").
3. Our reset function calls set_optical_parameters() 4 times
љљ through wrapper functions:
љљ - contrast
љљ - brightness
љљ - hue
љљ - saturation
4. Together with the isoc_init in the usb subsystem, the buffer system
љљ initializing itself and mplayer loading libv4l in userspace my computer
љљ can't cope and locks up.

љљ Hopefully removing the wrappers as I suggested before will fix this.

љљ GWater


2009/3/25 Boris Borisov <lz1...@gmail.com>