[linux-dvb] Re: Can the auto symbol rate patch for mt312 bemerged?

[Roberto Ragusa <mail@robertoragusa.it>]

On Mon, 06 Sep 2004 11:33:39 +0200
Holger Waechtler <holger@qanu.de> wrote:


> Just go on and add your code, as long no other hardware supports these 
> capabilities a "private" API should be ok. Please don't add your ioctls 
> in the linux/include/frontend.h file but keep them private in a include 
> file shared between mt312.c and your userspace scan application, as soon 
> we have a fixed API both would need to get touched again anyways. For 
> now they are too specific tied to the mt312.

I don't think I've understood what you mean.
As my first goal is to avoid the need to recompile the kernel to have
blindscan capability and as some kernel support is required to do this, it
is necessary to at least have an undocumented kernel feature (e.g. the
mt312 frontend accepts strange symbol rate values, which should be normally
rejected); which I dislike, as it's not an acceptable behaviour from my
point of view, expecially in free software.

So the choice is between:
- having a minimally invasive, hacked, somewhat documented feature for mt312
only (my first idea: sending the range bitmask as symbol rate)
- creating a modest API extension, ready for adoption by other frontends
and well documented as a feature which could be available or not
(FE_HAS_AUTO_SYMBOL_RATE) (my second idea: introducing an ioctl to set
the range before tuning)

Are you saying that even the 2nd choice is too invasive for you?
The patch is really small and clean, just a new ioctl which passes a
struct containing two integers.

Please note that in my blindscan 0.2 mail the first patch is only there
to avoid rejects due to code restyling, but the core of the changes is
almost trivial (second patch).

I hope we can finally agree.
I don't want the auto sr feature to be still delayed for Linux when it's
readily available on Windows (where there could be a clean API or a hackish
hardware access, I don't care; but it's there, while we don't support the
hardware fully).

Best regards.
-- 
   Roberto Ragusa    mail at robertoragusa.it