linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Antti Palosaari <crope@iki.fi>
Cc: VDR User <user.vdr@gmail.com>,
	Devin Heitmueller <dheitmueller@kernellabs.com>,
	linux-media <linux-media@vger.kernel.org>,
	Patrick Boettcher <pboettcher@kernellabs.com>
Subject: Re: [RFCv1] DVB-USB improvements [alternative 2]
Date: Mon, 21 May 2012 00:44:45 -0300	[thread overview]
Message-ID: <4FB9BA2D.7080107@redhat.com> (raw)
In-Reply-To: <db7c5a642248378318b5c89e99819eb5.squirrel@webmail.kapsi.fi>

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 <crope@iki.fi> 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 fish to fry. But this is not an urgent
>>>> project and I disagree with the attitude to just disregard whatever
>>>> you deem unimportant. If you're going to do it, do it right.
>>>
>>> I am not sure what you trying to say. Do you mean I should try to get
>>> remote
>>> controller totally optional module which can be left out?
>>
>> I am saying it's a dependency that is currently forced onto every usb
>> device whether the device even supports rc or not. This is clearly
>> poor design. For that matter, the whole usb handling must be poor
>> design if it needs to be overhauled.
>>
>>> How much memory will be saved if remote can be left out as unloaded?
>>
>> I don't know. I'm merely pointing out just one of the issues that
>> should be resolved if the idea is to fix things that are wrong with
>> usb handling. If nobody cares, doesn't think it matters, or simply
>> doesn't want to bother, so be it. I guess I'm crazy but when I'm
>> facing an overhaul, especially when there's no rush, I compile a list
>> of _everything_ that's wrong and make sure the overhaul fixes it all.
>> I guess there's quite a difference between my idea of what an overhaul
>> should be, and other peoples.
>>
>> If you really want, there's probably people who deal with embedded
>> systems where every wasted byte counts, that would agree cleaning up
>> the waste is a good idea.
>>
>> Since nobody thinks it should be fixed, just pretend I didn't even
>> bring it up. Problem solved.
> 
> There is quite few devices that are shipped without remote. I agree that
> it could be better and more modular. And it is asked multiple times during
> these years. But my main motivation is to fix problems first and then do
> enhancements. I will look if I can found some time for that too.

I see two separate issues here:

1) the dvb_usb properties struct needs to point if the device has RC or not.
It could be possible to optimize it if the remote code is not enabled, but
provided that the structure is properly designed, the only per-device information
is the RC keytable. Optimizing it when IR is not compiled will save just
a few bytes per card. Not worth, IMHO.

2) Remove the RC dependency from dvb-usb, and making the dvb-usb-remote code
as a module. This can bring some savings, as the RC core and IR decoders won't
be loaded.

I think (2) is valuable to do, but this can be done latter with a likely simple
patch, and won't require any changes at the DVB structures.

Regards,
Mauro

  reply	other threads:[~2012-05-21  3:44 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-20 20:55 [RFCv1] DVB-USB improvements [alternative 2] Antti Palosaari
2012-05-20 22:30 ` VDR User
2012-05-20 23:10   ` Devin Heitmueller
2012-05-21  0:36     ` VDR User
2012-05-21  2:22       ` Antti Palosaari
2012-05-21  2:42         ` VDR User
2012-05-21  3:20           ` Antti Palosaari
2012-05-21  3:44             ` Mauro Carvalho Chehab [this message]
2012-05-21  3:50 ` Mauro Carvalho Chehab
2012-05-25 17:44   ` Antti Palosaari
2012-05-25 17:48     ` Antti Palosaari
2012-05-25 18:32     ` Mauro Carvalho Chehab
2012-05-25 18:38       ` Mauro Carvalho Chehab
2012-05-25 18:51       ` Antti Palosaari

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FB9BA2D.7080107@redhat.com \
    --to=mchehab@redhat.com \
    --cc=crope@iki.fi \
    --cc=dheitmueller@kernellabs.com \
    --cc=linux-media@vger.kernel.org \
    --cc=pboettcher@kernellabs.com \
    --cc=user.vdr@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).