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
> 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
> --~--~---------~--~----~------------~-------~--~----~ > Lets make microdia webcams plug'n play, (currently plug'n pray) > To post to this group, send email to microdia@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?)
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.
<grewa...@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
> 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?)
Brian Johnson wrote:
> 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
> Brian Johnson wrote:
>> 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
> Ok If noone has any issues with these patches i'm going to push them > when i get home later this this evening.
> On Mon, Mar 23, 2009 at 2:46 PM, Pablo Castellano
> <pablog.ubu...@gmail.com> wrote: > > Brian Johnson wrote: > >> 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
> > Nice job! This is the only thing I can say :)
> > -- > > Regards, Pablo.
> --~--~---------~--~----~------------~-------~--~----~ > Lets make microdia webcams plug'n play, (currently plug'n pray) > To post to this group, send email to microdia@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.
<grewa...@googlemail.com> wrote:
> Am Dienstag 24 März 2009 17:32:28 schrieb 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.
>> On Mon, Mar 23, 2009 at 2:46 PM, Pablo Castellano
>> <pablog.ubu...@gmail.com> wrote:
>> > Brian Johnson wrote:
>> >> 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
>> > Nice job! This is the only thing I can say :)
>> > --
>> > Regards, Pablo.
>> > 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.
>>>>> 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
>>>> Nice job! This is the only thing I can say :)
>>>> --
>>>> Regards, Pablo.
>>>> 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.
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.
> Brian
> You are not push the patch for control of hie and saturation.
> Brian Johnson wrote:
> Pushed
> On Tue, Mar 24, 2009 at 12:38 PM, Josua Grawitter<grewa...@googlemail.com> <grewa...@googlemail.com> wrote:
> Am Dienstag 24 Mдrz 2009 17:32:28 schrieb 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.
> On Mon, Mar 23, 2009 at 2:46 PM, Pablo Castellano
> <pablog.ubu...@gmail.com> <pablog.ubu...@gmail.com> wrote:
> Brian Johnson wrote:
> 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
> Nice job! This is the only thing I can say :)
> --
> Regards, Pablo.
> 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.
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.
> 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.
>> 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
>> Nice job! This is the only thing I can say :)
>> --
>> Regards, Pablo.
>> 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.
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.
>> 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.
>>> 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
>>> Nice job! This is the only thing I can say :)
>>> --
>>> Regards, Pablo.
>>> 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.
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?
> 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 <grewa...@googlemail.com> <grewa...@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> <lz1...@gmail.com>
> Brian
> You are not push the patch for control of hie and saturation.
> Brian Johnson wrote:
> Pushed
> On Tue, Mar 24, 2009 at 12:38 PM, Josua Grawitter<grewa...@googlemail.com> <grewa...@googlemail.com>
> wrote:
> Am Dienstag 24 MДrz 2009 17:32:28 schrieb 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.
> On Mon, Mar 23, 2009 at 2:46 PM, Pablo Castellano
> 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
> Nice job! This is the only thing I can say :)
> --
> Regards, Pablo.
> 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.
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?
On Wed, Mar 25, 2009 at 6:26 PM, Gray Water <grewa...@googlemail.com> wrote:
> 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?
>> 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 <grewa...@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.
>> 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
>> Nice job! This is the only thing I can say :)
>> --
>> Regards, Pablo.
>> 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.
Brian Johnson wrote:
> 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?
> On Wed, Mar 25, 2009 at 6:26 PM, Gray Water <grewa...@googlemail.com> wrote:
>> 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?
>>> 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 <grewa...@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.
>>> 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
>>> Nice job! This is the only thing I can say :)
>>> --
>>> Regards, Pablo.
>>> 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.
