On 25.05.2012 21:32, Mauro Carvalho Chehab wrote:
Em 25-05-2012 14:44, Antti Palosaari escreveu:
On 21.05.2012 06:50, Mauro Carvalho Chehab wrote:
Em 20-05-2012 17:55, Antti Palosaari escreveu:
I did some more planning and made alternative RFC.
As the earlier alternative was more like changing
Em 25-05-2012 15:32, Mauro Carvalho Chehab escreveu:
> Em 25-05-2012 14:44, Antti Palosaari escreveu:
>> On 21.05.2012 06:50, Mauro Carvalho Chehab wrote:
>>> Em 20-05-2012 17:55, Antti Palosaari escreveu:
I did some more planning and made alternative RFC.
As the earlier alternative was m
Em 25-05-2012 14:44, Antti Palosaari escreveu:
> On 21.05.2012 06:50, Mauro Carvalho Chehab wrote:
>> Em 20-05-2012 17:55, Antti Palosaari escreveu:
>>> I did some more planning and made alternative RFC.
>>> As the earlier alternative was more like changing old functionality that
>>> new one goes
On 25.05.2012 20:44, Antti Palosaari wrote:
I have now implemented some basic stuff. Most interesting is new way of
map device id and properties for it. I found that I can use .driver_info
field from the (struct usb_device_id) to carry pointer. I used it to
carry all the other data to the DVB USB
On 21.05.2012 06:50, Mauro Carvalho Chehab wrote:
Em 20-05-2012 17:55, Antti Palosaari escreveu:
I did some more planning and made alternative RFC.
As the earlier alternative was more like changing old functionality that new
one goes much more deeper.
As a basic rule I designed it to reduce st
Em 20-05-2012 17:55, Antti Palosaari escreveu:
> I did some more planning and made alternative RFC.
> As the earlier alternative was more like changing old functionality that new
> one goes much more deeper.
>
> As a basic rule I designed it to reduce stuff from the current struct
> dvb_usb_devi
Em 21-05-2012 00:20, Antti Palosaari escreveu:
> ma 21.5.2012 5:42 VDR User kirjoitti:
>> On Sun, May 20, 2012 at 7:22 PM, Antti Palosaari wrote:
So you think that it makes more sense to ignore existing issues rather
than fix them. Isn't fixing issues& flaws the whole point of an
o
ma 21.5.2012 5:42 VDR User kirjoitti:
> On Sun, May 20, 2012 at 7:22 PM, Antti Palosaari wrote:
>>> So you think that it makes more sense to ignore existing issues rather
>>> than fix them. Isn't fixing issues& flaws the whole point of an
>>> overhaul/redesign? Yes, it is. I do get the point you'
On Sun, May 20, 2012 at 7:22 PM, Antti Palosaari wrote:
>> So you think that it makes more sense to ignore existing issues rather
>> than fix them. Isn't fixing issues& flaws the whole point of an
>> overhaul/redesign? Yes, it is. I do get the point you're trying to
>> make -- there are bigger fi
On 21.05.2012 03:36, VDR User wrote:
On Sun, May 20, 2012 at 4:10 PM, Devin Heitmueller
wrote:
If you think this is important, then you should feel free to submit
patches to Antti's tree. Otherwise, this is the sort of optimization
that brings so little value as to not really be worth the eng
On Sun, May 20, 2012 at 4:10 PM, Devin Heitmueller
wrote:
> If you think this is important, then you should feel free to submit
> patches to Antti's tree. Otherwise, this is the sort of optimization
> that brings so little value as to not really be worth the engineering
> effort. The time is bet
On Sun, May 20, 2012 at 6:30 PM, VDR User wrote:
> On Sun, May 20, 2012 at 1:55 PM, Antti Palosaari wrote:
>> I did some more planning and made alternative RFC.
>> As the earlier alternative was more like changing old functionality that new
>> one goes much more deeper.
>
>> Functionality enhance
On Sun, May 20, 2012 at 1:55 PM, Antti Palosaari wrote:
> I did some more planning and made alternative RFC.
> As the earlier alternative was more like changing old functionality that new
> one goes much more deeper.
> Functionality enhancement mentioned earlier RFC are valid too:
> http://www.ma
On 10.05.2012 17:14, Mauro Carvalho Chehab wrote:
Em 08-05-2012 10:12, Antti Palosaari escreveu:
Factors behind the changes are mostly coming from the fact current struct
dvb_usb_device_properties contains so many static configuration options.
You cannot change single dvb_usb_device_properties
On Thu, May 10, 2012 at 10:14 AM, Mauro Carvalho Chehab
wrote:
> In order to add analog support, it is likely simpler to take em28xx (mainly
> em28xx-video) as an
> example on how things are implemented on analog side. The gspca
> implementation may also help a
> lot, but it doesn't contain the
Em 08-05-2012 10:12, Antti Palosaari escreveu:
> Factors behind the changes are mostly coming from the fact current struct
> dvb_usb_device_properties contains so many static configuration options.
> You cannot change single dvb_usb_device_properties easily (safely) at runtime
> since it is usual
On 08.05.2012 20:55, Markus Rechberger wrote:
You might also work on a dvb library, just like libv4l has right now,
that might satisfy the streaming requests which have been made on this
mailinglist :-)
I want first fix general DVB issues I has met during these years. Maybe
library can be done
On Tue, May 8, 2012 at 3:12 PM, Antti Palosaari wrote:
> Factors behind the changes are mostly coming from the fact current struct
> dvb_usb_device_properties contains so many static configuration options. You
> cannot change single dvb_usb_device_properties easily (safely) at runtime
> since it i
18 matches
Mail list logo
