Am 08.04.2010 02:47, schrieb Mike Isely:
On Thu, 8 Apr 2010, hermann pitton wrote:
Hi,
Am Mittwoch, den 07.04.2010, 20:50 +0200 schrieb Lars Hanisch:
Am 06.04.2010 16:33, schrieb Mike Isely:
[snip]
Mike, do you know of anyone actively using that additional information?
Yes.
The VDR proj
On Wed, 7 Apr 2010, Mike Isely wrote:
>
> Backwards compatibility is very important and thus any kind of new
> interface deserves a lot of forethought to ensure that choices are made
> in the present that people will regret in the future. Making an
"in the present that people will NOT (!!) r
On Wed, 7 Apr 2010, Hans Verkuil wrote:
[...]
>
> Perhaps we should just not do this in sysfs at all but in debugfs? We have a
> lot more freedom there. No requirement of one-value-per-file, and if we need
> to we can change things in the future. It would actually be easier to issue
> ioctl c
On Thu, 8 Apr 2010, hermann pitton wrote:
> Hi,
>
> Am Mittwoch, den 07.04.2010, 20:50 +0200 schrieb Lars Hanisch:
> > Am 06.04.2010 16:33, schrieb Mike Isely:
> [snip]
> > >>
> > >> Mike, do you know of anyone actively using that additional information?
> > >
> > > Yes.
> > >
> > > The VDR proje
Hi,
Am Mittwoch, den 07.04.2010, 20:50 +0200 schrieb Lars Hanisch:
> Am 06.04.2010 16:33, schrieb Mike Isely:
[snip]
> >>
> >> Mike, do you know of anyone actively using that additional information?
> >
> > Yes.
> >
> > The VDR project at one time implemented a plugin to directly interface
> > to
Am 06.04.2010 16:33, schrieb Mike Isely:
Comments below...
On Mon, 5 Apr 2010, Hans Verkuil wrote:
Hi all,
The new control framework makes it very easy to expose controls in sysfs.
The way it is implemented now in the framework is that each device node
will get a 'controls' subdirectory in s
On Wednesday 07 April 2010 00:39:20 Hans Verkuil wrote:
> On Tuesday 06 April 2010 17:16:17 Mike Isely wrote:
> > On Tue, 6 Apr 2010, Laurent Pinchart wrote:
> >
> > > Hi Andy,
> > >
> > > On Tuesday 06 April 2010 13:06:18 Andy Walls wrote:
> > > > On Tue, 2010-04-06 at 08:37 +0200, Hans Verkuil
Hi,
Am Mittwoch, den 07.04.2010, 00:39 +0200 schrieb Hans Verkuil:
> On Tuesday 06 April 2010 17:16:17 Mike Isely wrote:
> > On Tue, 6 Apr 2010, Laurent Pinchart wrote:
> >
> > > Hi Andy,
> > >
> > > On Tuesday 06 April 2010 13:06:18 Andy Walls wrote:
> > > > On Tue, 2010-04-06 at 08:37 +0200, H
On Tuesday 06 April 2010 18:19:30 Jonathan Cameron wrote:
> On 04/06/10 15:41, Mike Isely wrote:
> > On Tue, 6 Apr 2010, Hans Verkuil wrote:
> >
> >[...]
> >
> >>
> >> One thing that might be useful is to prefix the name with the control class
> >> name. E.g. hue becomes user_hue and audio_cr
On Tuesday 06 April 2010 17:16:17 Mike Isely wrote:
> On Tue, 6 Apr 2010, Laurent Pinchart wrote:
>
> > Hi Andy,
> >
> > On Tuesday 06 April 2010 13:06:18 Andy Walls wrote:
> > > On Tue, 2010-04-06 at 08:37 +0200, Hans Verkuil wrote:
> >
> > [snip]
> >
> > > > Again, I still don't know whether
On 6 April 2010 18:06, Jonathan Cameron wrote:
> On 04/06/10 15:32, Mauro Carvalho Chehab wrote:
>> Hans Verkuil wrote:
Hans Verkuil wrote:
> $ ls /sys/class/video4linux/video1/controls
> balance mpeg_insert_navigation_packets
> mpeg_video_aspect
> br
On 04/06/10 15:41, Mike Isely wrote:
> On Tue, 6 Apr 2010, Hans Verkuil wrote:
>
>[...]
>
>>
>> One thing that might be useful is to prefix the name with the control class
>> name. E.g. hue becomes user_hue and audio_crc becomes mpeg_audio_crc. It
>> would
>> groups them better. Or one could
On 04/06/10 15:32, Mauro Carvalho Chehab wrote:
> Hans Verkuil wrote:
>>> Hans Verkuil wrote:
$ ls /sys/class/video4linux/video1/controls
balance mpeg_insert_navigation_packets
mpeg_video_aspect
brightnessmpeg_median_chroma_filte
On Tue, 6 Apr 2010, Laurent Pinchart wrote:
> Hi Andy,
>
> On Tuesday 06 April 2010 13:06:18 Andy Walls wrote:
> > On Tue, 2010-04-06 at 08:37 +0200, Hans Verkuil wrote:
>
> [snip]
>
> > > Again, I still don't know whether we should do this. It is dangerously
> > > seductive because it would be
On Tue, 6 Apr 2010, Markus Rechberger wrote:
[...]
>
> how about security permissions? while you can easily change the
> permission levels for nodes in /dev you can't do this so easily with
> sysfs entries.
> I don't really think this is needed at all some applications will
> start to use ioc
On Tue, 6 Apr 2010, Devin Heitmueller wrote:
[...]
>
> I tend to agree with Hans. We've already got *too many* interfaces
> that do the same thing. The testing matrix is already a nightmare -
> V4L1 versus V4L2, mmap() versus read(), legacy controls versus
> extended controls, and don't get
On Tue, 6 Apr 2010, Hans Verkuil wrote:
[...]
>
> One thing that might be useful is to prefix the name with the control class
> name. E.g. hue becomes user_hue and audio_crc becomes mpeg_audio_crc. It would
> groups them better. Or one could make a controls/user and controls/mpeg
> directory.
Comments below...
On Mon, 5 Apr 2010, Hans Verkuil wrote:
> Hi all,
>
> The new control framework makes it very easy to expose controls in sysfs.
> The way it is implemented now in the framework is that each device node
> will get a 'controls' subdirectory in sysfs. Below which are all the cont
Hans Verkuil wrote:
>> Hans Verkuil wrote:
>>> $ ls /sys/class/video4linux/video1/controls
>>> balance mpeg_insert_navigation_packets
>>> mpeg_video_aspect
>>> brightnessmpeg_median_chroma_filter_maximum
>>> mpeg_video_b_frames
>>> chroma_agc
On Tue, Apr 6, 2010 at 9:44 AM, Hans Verkuil wrote:
> 1) We don't have that information.
> 2) It would make a simple scheme suddenly a lot more complicated (see
> Andy's comments)
> 3) The main interface is always the application's GUI through ioctls, not
> sysfs.
> 4) Remember that ivtv has an un
> Hans Verkuil wrote:
>> $ ls /sys/class/video4linux/video1/controls
>> balance mpeg_insert_navigation_packets
>> mpeg_video_aspect
>> brightnessmpeg_median_chroma_filter_maximum
>> mpeg_video_b_frames
>> chroma_agcmpeg_medi
Hans Verkuil wrote:
> On Tuesday 06 April 2010 00:12:48 Hans Verkuil wrote:
>> On Monday 05 April 2010 23:47:10 Hans Verkuil wrote:
>>> Hi all,
>>>
>>> The new control framework makes it very easy to expose controls in sysfs.
>>> The way it is implemented now in the framework is that each device no
On Tue, Apr 6, 2010 at 1:27 PM, Laurent Pinchart
wrote:
> Hi Andy,
>
> On Tuesday 06 April 2010 13:06:18 Andy Walls wrote:
>> On Tue, 2010-04-06 at 08:37 +0200, Hans Verkuil wrote:
>
> [snip]
>
>> > Again, I still don't know whether we should do this. It is dangerously
>> > seductive because it wo
Hi Andy,
On Tuesday 06 April 2010 13:06:18 Andy Walls wrote:
> On Tue, 2010-04-06 at 08:37 +0200, Hans Verkuil wrote:
[snip]
> > Again, I still don't know whether we should do this. It is dangerously
> > seductive because it would be so trivial to implement.
>
> It's like watching ships run agr
On Tue, 2010-04-06 at 08:37 +0200, Hans Verkuil wrote:
> On Tuesday 06 April 2010 00:12:48 Hans Verkuil wrote:
> > On Monday 05 April 2010 23:47:10 Hans Verkuil wrote:
> > One thing that might be useful is to prefix the name with the control class
> > name. E.g. hue becomes user_hue and audio_cr
On Tuesday 06 April 2010 00:12:48 Hans Verkuil wrote:
> On Monday 05 April 2010 23:47:10 Hans Verkuil wrote:
> > Hi all,
> >
> > The new control framework makes it very easy to expose controls in sysfs.
> > The way it is implemented now in the framework is that each device node
> > will get a 'con
On Monday 05 April 2010 23:47:10 Hans Verkuil wrote:
> Hi all,
>
> The new control framework makes it very easy to expose controls in sysfs.
> The way it is implemented now in the framework is that each device node
> will get a 'controls' subdirectory in sysfs. Below which are all the controls
> a
Hi all,
The new control framework makes it very easy to expose controls in sysfs.
The way it is implemented now in the framework is that each device node
will get a 'controls' subdirectory in sysfs. Below which are all the controls
associated with that device node.
So different device nodes can h
28 matches
Mail list logo
