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 usually driver global struct and thus
shared between all t
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
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
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 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
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
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_device_properties. Currently there is many nested structs
in
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 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 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 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 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
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'
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
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
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
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
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
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
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
20 matches
Mail list logo
