Hi Laurie,
Thanks for testing and feedback!
On Thu, 30 Jul 2020 08:07:56 +0100
Laurence Tratt wrote:
> On Wed, Jul 29, 2020 at 10:52:31PM +0200, Marcus Glocker wrote:
>
> Hello Marcus,
>
> > Slightly adapted diff; Negative numbers can happen on controls.
>
> This looks really good to me,
On Wed, Jul 29, 2020 at 10:52:31PM +0200, Marcus Glocker wrote:
Hello Marcus,
> Slightly adapted diff; Negative numbers can happen on controls.
This looks really good to me, and a significant improvement on my original.
I've tested everything I can think of and it all looks good, with one mild
On Wed, 29 Jul 2020 07:45:52 +0200
Marcus Glocker wrote:
> On Sat, 25 Jul 2020 18:27:45 +0100
> Laurence Tratt wrote:
>
> > On Sat, Jul 25, 2020 at 10:27:15AM -0600, Theo de Raadt wrote:
> >
> > Hello Theo,
> >
> > > My primary concern is about a user changing settings which then
> > >
On Sat, 25 Jul 2020 18:27:45 +0100
Laurence Tratt wrote:
> On Sat, Jul 25, 2020 at 10:27:15AM -0600, Theo de Raadt wrote:
>
> Hello Theo,
>
> > My primary concern is about a user changing settings which then
> > persist past close.
> >
> > Upon re-open, how do they know what mode they are in?
On Sat, Jul 25, 2020 at 10:27:15AM -0600, Theo de Raadt wrote:
Hello Theo,
> My primary concern is about a user changing settings which then persist
> past close.
>
> Upon re-open, how do they know what mode they are in?
>
> I understand the default mode for a camera might not be nice. But at
On Sat, Jul 25, 2020 at 10:27:15AM -0600, Theo de Raadt wrote:
> Matthieu Herrb wrote:
>
> > On Sat, Jul 25, 2020 at 09:17:24AM -0600, Theo de Raadt wrote:
> > > Marcus Glocker wrote:
> > >
> > > > Instead of introducing the CLI parameter controls in video(1), we could
> > > > introduce
Stuart Henderson wrote:
> On 2020/07/25 09:20, Theo de Raadt wrote:
> > The normal idiom is when last-close happens in a driver, all modal-state
> > is lost and restored to default, and when you use the driver again --
> > the new open gets you a raw configuration which is then changed via
> >
On 2020/07/25 09:20, Theo de Raadt wrote:
> The normal idiom is when last-close happens in a driver, all modal-state
> is lost and restored to default, and when you use the driver again --
> the new open gets you a raw configuration which is then changed via
> ioctl, before futher use.
Isn't this
Matthieu Herrb wrote:
> On Sat, Jul 25, 2020 at 09:17:24AM -0600, Theo de Raadt wrote:
> > Marcus Glocker wrote:
> >
> > > Instead of introducing the CLI parameter controls in video(1), we could
> > > introduce videoctl(1) in base, same as we have with audioctl(1). This
> > > also gives us
On Sat, Jul 25, 2020 at 09:17:24AM -0600, Theo de Raadt wrote:
> Marcus Glocker wrote:
>
> > Instead of introducing the CLI parameter controls in video(1), we could
> > introduce videoctl(1) in base, same as we have with audioctl(1). This
> > also gives us the possibility to only display the
$ video -c white_balance_temperature=6500
$ video
$ video -c reset
$ video
BTW, no other subsystem of ours has this "reset" type thing.
A few subsystems have persistance, but persistant modes are usually only
in the software layer, not in the hardware layer.
The normal idiom is when
Marcus Glocker wrote:
> Instead of introducing the CLI parameter controls in video(1), we could
> introduce videoctl(1) in base, same as we have with audioctl(1). This
> also gives us the possibility to only display the current video
> parameters.
I must have missed something. Why does it
On Fri, 24 Jul 2020 15:13:19 +0100
Laurence Tratt wrote:
> On Thu, Jul 23, 2020 at 09:56:39PM +0200, Marcus Glocker wrote:
>
> Hello Marcus,
>
> > We read the current value of the white balance temperature auto
> > control (since this gets set correctly during the reset), and just
> > reset it
On Thu, Jul 23, 2020 at 09:56:39PM +0200, Marcus Glocker wrote:
Hello Marcus,
> We read the current value of the white balance temperature auto control
> (since this gets set correctly during the reset), and just reset it again
> on the next cam start up after the video stream has been started?
Hi Laurie,
On Thu, 23 Jul 2020 21:07:26 +0100
Laurence Tratt wrote:
> On Thu, Jul 23, 2020 at 09:56:39PM +0200, Marcus Glocker wrote:
>
> Hello Marcus,
>
> > We read the current value of the white balance temperature auto
> > control (since this gets set correctly during the reset), and just
On Thu, Jul 23, 2020 at 09:56:39PM +0200, Marcus Glocker wrote:
Hello Marcus,
> We read the current value of the white balance temperature auto control
> (since this gets set correctly during the reset), and just reset it again
> on the next cam start up after the video stream has been started?
On Wed, 22 Jul 2020 21:52:27 +0100
Laurence Tratt wrote:
> On Wed, Jul 22, 2020 at 10:23:19PM +0200, Marcus Glocker wrote:
>
> Hello Marcus,
>
> > I've tested this here as well in the meantime by leaving
> > mmap_init() on its original location (doesn't get involved for '-c
> > reset') with
On Wed, Jul 22, 2020 at 10:23:19PM +0200, Marcus Glocker wrote:
Hello Marcus,
> I've tested this here as well in the meantime by leaving mmap_init() on
> its original location (doesn't get involved for '-c reset') with three
> different cams:
>
> * Logitech C930e: I see the same problem like
Hello Laurie,
On Tue, 21 Jul 2020 21:18:15 +0100
Laurence Tratt wrote:
> On Tue, Jul 21, 2020 at 09:01:26PM +0200, Marcus Glocker wrote:
>
> Hello Marcus,
>
> Thanks for the comments! Again, I agree with all of them with a
> couple of comments:
>
> > I'm a bit confused by the dev_set_ctrl()
On Tue, Jul 21, 2020 at 09:01:26PM +0200, Marcus Glocker wrote:
Hello Marcus,
Thanks for the comments! Again, I agree with all of them with a couple of
comments:
> I'm a bit confused by the dev_set_ctrl() function renaming. Does 'inc'
> stand for increment? And if yes, it makes not a lot sense
Hi Laurie,
See my comments inline.
On Fri, 17 Jul 2020 22:51:30 +0100
Laurence Tratt wrote:
> On Mon, Jul 13, 2020 at 07:39:41PM +0100, Laurence Tratt wrote:
>
> > video(1) allows users to adjust controls such as brightness,
> > saturation (etc.) depending on the input device in question.
On Mon, Jul 13, 2020 at 07:39:41PM +0100, Laurence Tratt wrote:
> video(1) allows users to adjust controls such as brightness, saturation
> (etc.) depending on the input device in question. These values persist even
> after video(1) has quit, allowing you to e.g. increase the brightness of a
>
video(1) allows users to adjust controls such as brightness, saturation
(etc.) depending on the input device in question. These values persist even
after video(1) has quit, allowing you to e.g. increase the brightness of a
webcam before connecting to a video call. However, the only way to adjust
23 matches
Mail list logo
