Re: [linux-dvb] DVB-S2 API vs. HVR4000: When?
On Monday 05 November 2007, Johannes Stezenbach wrote:
On Mon, Nov 05, 2007, Steven Toth wrote:
Johannes Stezenbach wrote:
struct dvb_tuning_param p[3] = {
{ .id = MODULATION, .val = MOD_8VSB },
{ .id = FREQUENCY, .val = 59125 },
{ .id = 0 }
};
ioctl(fd, DVB_TUNE, p);
You can't reliably pass in variably length arrays into the kernel, or none
of the other kernel wide drivers do, they need to be fixed length for
sanity reasons.
Of course you can have variable length args to ioctl(). It's
just that you can't let dvb_usercopy() do the work anymore but
have to call copy_from_user() yourself, but I would favor a simple,
generic API anytime over one with unnecessary, arbitrary
limits, so IMHO it's worth the little extra effort.
#define DVB_TUNE _IOC(_IOC_WRITE,'o',82,0)
plus
diff -r 1acfe4149714 linux/drivers/media/dvb/dvb-core/dvbdev.c
--- a/linux/drivers/media/dvb/dvb-core/dvbdev.c Mon Nov 05 10:30:39
2007 -0200
+++ b/linux/drivers/media/dvb/dvb-core/dvbdev.c Mon Nov 05 18:23:41
2007 +0100
@@ -362,9 +362,11 @@ int dvb_usercopy(struct inode *inode, st
case _IOC_READ: /* some v4l ioctls are marked wrong ... */
case _IOC_WRITE:
case (_IOC_WRITE | _IOC_READ):
- if (_IOC_SIZE(cmd) = sizeof(sbuf)) {
+ if (_IOC_SIZE(cmd) == 0)
+ parg = arg;
+ else if (_IOC_SIZE(cmd) = sizeof(sbuf))
parg = sbuf;
- } else {
+ else {
/* too big to allocate from stack */
mbuf = kmalloc(_IOC_SIZE(cmd),GFP_KERNEL);
if (NULL == mbuf)
(untested)
(BTW, the majority of ioctls don't encode the argument size, this
feature was invented just a few years ago; see man ioctl_list)
Or you could encode the lenght seperately like e.g.
I2C_RDWR does with its struct i2c_rdwr_ioctl_data argument.
It's a matter of taste, not sanity or security.
1) I've made minor changes to dvb_core to interpret these messages and
handle the ioctl. No changes have been made to the frontend drivers.
2) Adding support for s2 _inside_ the kernel will mean adding a single
method to dvb_frontend_ops which allows the dvb_core to notify a new S2
driver. The goal here is to minimize these changes also. I haven't
demonstrated that code here, becuse I felt it was more important to show
the impact to the userland API/ABI, knowing that DVB-S2 and other advanced
types (including analog) would naturally fit well within this model.
3) This applies to all devs. I welcome all feedback, for sure the sytax
might need some cleanup, but please don't shoot the idea down when it's
only had 6-8 hours work of engineering behind it. It's proof of concept. It
doesn't contain any of Manu's code so I don't feel bound politically or
technically. I think given another 4-5 hours I could show the HVR4000
working, and demonstrate many of the userland signal/statistic API's.
At this stage I'm looking for a Yes, in principle we like the idea, but
show me how you do feature XYZ from other devs. At which point I'll flush
out more code this would probably lead to an RFC for your approval.
Seems like no one is interested.
BTW, since every DVB-S2 demod is also a DVB-S demod, why does
no one split the DVB-S parts of their driver for merging
first? It would make the users happy as it would change the
state from card not supported to card works for 95% of existing
transponders. (Dunno how this fits into this thread but...)
hi everybody,
what are we doing now?
imho we are discussing a new change to the dvb-s2 api again.
although i do like this ioctl approach for further enhancements of the api,
i must admit that things that are already done have to be done again.
iirc, there is a multiproto version of szap, vdr, ...
although, existing drivers e.g. stb0899 must be rewritten/patched to handle the
new iotcl.
at least i do not know what this will mean to the rework and test scenario,
on both sides. this means if we take multiproto from manu - what has steven got
to do,
and, if we take stevens approach, whats on manus side.
i would really appreciate to get a working compromise instead of starting this
api extension
all over again for the X time since Nov. 2005 when - iirc felix domke and me -
started the discussion.
Yes, in principle I like the idea but someday we must get an end to the
implementation and
merge it.
best regards
marcel
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Future of Multiproto
hi, can everybody _please_ stop this unnessessary discussion? manu, nobody is playing politics in the moment, not johannes, not steven, not anyone else. maybe sometimes it is hard to understand what people want to say if you have all the bad past in mind. what was said in coherence to your multiproto api change is just as simple as follows: please state if you are ready to merge multiproto to the main repository, whatever way it will take into. steven has got a ready driver, that demonstrated your api is fine and works, you have got your stb0899 driver nearly done, and also beside some small problems due to the device, its also proven working. if there is something missing from dvb-s2 specs that is not needed to actually watch tv, dont take any care on that to prevent multiproto to be merged. we can get rid of _all_ the momentary stupid discussions if you are ready to merge it. thus we could go back concentrate developing stuff, merge it, satisfy endusers instead of having to spent all of our time to behave like linuxtv.childhood. HTH marcel ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB API update
Markus Rechberger schrieb: ---snip--- Why don't abstract the dvb layer from enduser applications and put a general library infront which does that version check and tries to keep things consistend to the end applications? The enduser applications would have to implement that API one time but it would help to keep unnecessary changes away from those applications and even allow to clean up things lateron without breaking all the applications... it's just a thought though.. Markus markus, even if i am ignored by you :) if you would like to check out dvb-apps, you may find a libdvbapi and that is a kind of user space wrapper for such issues. i dont know if it is completely done, working, whatever, but the approach you want itself , was already started a long time ago. i do not know how many people use this, but imho there are not so much. regards marcel ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVB API update
On Sunday 16 September 2007, Rainer.scherg wrote:
hi rainer,
Manu Abraham schrieb:
- a user structure for hardware specific data (e.g. retrieve
special data from a special frontend chip would be nice.
this should be optional (*NULL = not used or not implemented).
otherwise something like:
struct { char[xx] hw_info;
specific data...
} *;
Sounds good. In a tangent thought, in many cases when a special chip is
used sometimes there is an overall change in the hardware design.
In such a case, do you think, that if we abstract such an info, out as a
part of as a new object such as an adapter object, (such that more
information can be passed out clearly) would be a better approach,
rather than shoving everything we have into the frontend object ? (where
the adapter object becomes the parent object for all others)
Though i must say, that the frontend specific should be in the frontend,
but the adapter object could get the frontend specific information as a
part of it's own and present to the application. Though, you will be
able to query the frontend related information alone also, for carrying
around shorter chunks of data if the user wants to have only a small
subset of the information.
I did not made any deeper thoughts on how this could be implemented
best. What was the reason of this idea:
A university asked me some times ago, to enhance dvbsnoop to output
more detailled error reporting data than SIG, SNR, BER, UBLCK for
a specific frontend (DIBCOM3000).
In this case it was related to the frontend. As you stated, a special
object might be more useful and more flexible.
- API 3 is missing a a function for retrieving current frontend
settings (e.g. on SAT LNB settings). It would be sufficient, when
simply the last parameters set are returned.
Currently on API3 a second dvb application can change the frontend,
whithout any chance for the main dvb application to detect this
easily.
the dvb-core saving away the last successful LOCK state, will this help
? But in any case, the second application if it successfully lock's,
then this would change logically, since this becomes the
previous-previous successful locked state.
Is that what you meant, guess i didn't follow you correctly.
Following scenario (SAT):
Application 1 tunes device 2:
to freq 1234.567 MHz, V, HiBand, SAT 2, etc..
Application 2 tunes device 2:
to freq 1000.123 MHz, H, LoBand, SAT 1, etc..
Currently application 1 has no chance to query the current
frontend settings.
from my pov it would not be allowed to have application 2 tune to a different
transponder if application 1 still uses it.
and, where is the deep sense in this situation?
app 1 tunes to 1234
app 2 tunes to 1000... and therefore destroys app 1`s data
app 1 checks periodically (via get current tuning param),
if everything still is fine,
the result is this case is no, so app 1 would maybe
try to retune to 1234-- and app2 would check and try to retune to 100
i cant see sense in your example at all.
where i can see the sense is, to query a frontend to get back the actual
frontend settings,
but your example has a totally different problem.
In a first step, a simple query current frontend
settings (last set data) for a device would be sufficient.
In a second step (future APIs), one could think about notification
by event handlers.
which notification? a userspace application should free a frontends usage, if
is no longer
using it. am i wrong?
I also would ignore the LOCK state and always save/return the last
set parameters.
what do you mean with ignoring a LOCK state? also return frontend settings, if
no LOCK
has been done on those? if that is your point, i am ok for that.
regards
marcel
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] autoconf for dvb-apps
On Tuesday 11 September 2007, Christoph Pfister wrote: Hi, Am Dienstag 11 September 2007 schrieb gxk: To someone responsible for dvb-apps project Will you accept patch to add autoconf for dvb-apps? From my side (I'm theoretically only responsible for the scan files, practically I'm applying other patches as well if nobody else cares) I wouldn't accept / deal with it ... dunno about the other people. In general you should provide some reasoning, as the advantages have to be bigger in some kind than the disadvantages (in this case: different syntax, additional dependencies). But my own position is unlikely to change with regards to this. Christoph ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb hi, autofoo stuff can cause a lot of brain damage. if we would perform a change in the Makefile generation i would recommend cmake. it's at least easy to understand and works out quite well. regards marcel ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [Em28xx] MPL-licensed V4L kernel modules (em2880)
Markus Rechberger schrieb: For example you (first trying to help, afterwards doing nothing), * Manu Abraham (who has his project split from the maintree for a very long time too), its not really splitted, is it? imho it is just seperated by now as loads of changes are involved. from my knowledge, if its finished its merged into main repo again. * Marcel Siegert (who listens to other people's opinion and didn't even spend a minute on thinking by himself how to find a solution) BULLSHIT! - sorry for shouting - i made a proposal in IRC - do you remember? it was concerning NO dvb changes and your devices/drivers could have been merged without this still happening personal markus rechberger, i work for amd and i am the greatest discussion. next thing i proposed in irc in a private talk. german language was taken to absolutely be sure that NO misunderstanding will take part. what has your reaction been on that? like always - No, i wont agree to that kind of way i just proposed to merge ALL of your patches, and, afterwards to rework it to the better solution! that IS how community works, but you always regret to perform any kind of compromise! Facts are: your patches would have been merged already if you would have been more cooperative YOU missed all offers, like mine, or the one johannes did. you just complain about all those bad people in the linux dvb community you send cc's to your very own em28xx ml, and if someone does a normal reply all you blame him to spam your ml sorry markus, but you dont have to call others like buttlicker while not being able to look into a mirror. imho, i dont care what you do, but if you want to perform everything on your own as YOU said, please start over, and take away EVERYTHING! even these bloody damned discussions on the linuxdvb ml. and, dont start to cry if someone will take your old GPL'ed code, as a base to implement the devices in a acceptable way, and therefore will make your very own project/split off obsolete. without regards marcel ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [Em28xx] MPL-licensed V4L kernel modules (em2880)
forwarded to linuxdvb as i used my private not the list account :/ On Wednesday 11 July 2007, Markus Rechberger wrote: I would appreciate if you could stop spamming the em28xx ML since I prefer to use it for relevant issues; Currently there are around 200 people registered most of them aren't interested in internal linuxtv issues. Try to resolve all existing relevant problems first (since there are a few other problems out there within the linuxtv core developer(s) community) -Markus hey markus, please calm down again. YOU sended an email to linux-dvb ml including a cc to your very own em28xx ml. it is normal to REPLY TO ALL if someone answers this. dont claim johannes to spam the em28xx ml, as this is a discussion that again shows how non-cooperative _you_ are, you may just want not your users to know it! regards marcel ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] libdvbapi clarification
On Tuesday 10 July 2007, David Härdeman wrote:
I'm trying to understand the dvbdemux_set_section_filter function in
dvp-apps/lib/libdvbapi/dvbdemux.c (lines 74 - 93).
It used to take 16 filter and 16 mask parameters, but then it was changed
15 months ago to take 18 filter and 18 mask parameters, then it throws
away 2 of each:
int dvbdemux_set_section_filter(int fd, int pid,
uint8_t filter[18], uint8_t mask[18],
int start, int checkcrc)
{
struct dmx_sct_filter_params sctfilter;
memset(sctfilter, 0, sizeof(sctfilter));
sctfilter.pid = pid;
memcpy(sctfilter.filter.filter, filter, 1);
memcpy(sctfilter.filter.filter+1, filter+3, 15);
memcpy(sctfilter.filter.mask, mask, 1);
memcpy(sctfilter.filter.mask+1, mask+3, 15);
hi,
i think it was done due to following knowledge of the developer
if you filter a section you can filter on e.g. the table id but NOT on the size
ect.
(those are used as byte 2 + 3 of a section)
so if you would read the source normally, you would think you can filter on
those values.
having the two unused values within the filter array it makes life easier to
count the bytes
you want to filter and to set the right mask.
it can be more irretating than usefull, i must admit.
What is the purpose of this?
Second, how is the mask used? Would for example a filter value of 0x50 and
a mask of 0xf0 mean that all sections 0x50 - 0x5f would pass through the
section filter?
yes, the mask is used in that way.
best regards
marcel
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [Em28xx] MPL-licensed V4L kernel modules (em2880)
On Tuesday 10 July 2007, Markus Rechberger wrote: On 7/10/07, Jakob Petsovits [EMAIL PROTECTED] wrote: On Saturday, 7. July 2007, Markus Rechberger wrote: only my new sources are MPL licensed there; the v4l-dvb maincode is of course GPL. Even though it doesn't matter anymore the people who lead me to that step know how the code will get merged into the kernel now. It's out of the scope of linuxtv.org due useless delaying all that work. Er, excuse my baffledness, but how do you plan to get code merged into the kernel if it isn't GPL? there's nothing to worry about, the modified target code is GPL again. Also, mind that the GPL being viral means that any code which bases on GPL sources must be GPL (or GPL compatible) as well. Afaik, the MPL is not GPL compatible, so if you put your new code exclusively under the MPL and at the same time use the GPL-licensed v4l-dvb maincode as a base, you are violating the GPL. I am not a lawyer, of course. Please consult someone with good insight, for example, the Software Freedom Law Center at http://www.softwarefreedom.org/ Regards, Jakob ___ Em28xx mailing list [EMAIL PROTECTED] http://mcentral.de/mailman/listinfo/em28xx at least for my understanding, markus, please explain to me that, if you use v4l/dvb core functions that are licensed GPL, your code IS also GPL automatically, isn't it? and, as you told before, why is there a need to intermediate license to MPL? regards marcel ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [Bulk] Re: [Bulk] [linux-dvb] ati hdtv wonder in gentoo amd64
On Wednesday 11 April 2007, Markus Rechberger wrote: -- snip -- (didn't read everything here) but regarding I cannot emerge v4l-dvb-hg, I get build error /var/tmp/portage/media-tv/v4l-dvb-hg-0.1-r2/work/v4l-dvb/v4l/... try to compile it in /var/tmp/v4l-dvb instead that long path (so no v4l-dvb-hg-0.1-r2), some people had the same problems when checking out my repository in strange directorynames (I guess there's something wrong with a script but I haven't looked at it, it should work if you just compile it in a sane directoryname) Markus -- snip -- hi, markus your way would not work on gentoo systems using emerge/portage to compile sources. it uses a sandbox. you cant just change the behaviour (ok, there is a way, but not form normal users). it checks outs sources from repositories, unpacks, configures... everything. @brett can try to check out the sources manually and compile them? regards marcel ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Hotbird-13.0H patch
On Wednesday 04 April 2007, Salvatore De Paolis wrote: Here's a patch adding new transponders. Now i am able to scan 1773 services which is nice. applied. thanks marcel ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] bug in szap-utility
On Friday 09 March 2007, Uwe Bugla wrote: Original-Nachricht Datum: Tue, 06 Mar 2007 20:14:16 +0100 Von: Michel Verbraak [EMAIL PROTECTED] An: linux-dvb@linuxtv.org CC: Betreff: Re: [linux-dvb] bug in szap-utility Uwe Bugla schreef: Hi folks, as part of the Debain package dvb-utils 1.1.1-2 the szap utility has the following bug: 1. The start transponder file of Eutelsat Hotbird13.0E contains a H as description of the polarization. 2. Unfortunately this H is being interpreted as V. 3. So if you try to produce a transponder list with the start transponder you are trapped as nothing works! To see the error yourself, try the following example in the console: szap -r -a0 -c trapz.txt -n1 where trapz.txt looks like this: Hotbird-13.0E:12539:H:1:27500 With which program did you create the trapz.txt file? Salut Michel, with a program called pere which is a new revolutionary development as it scans a lot of more accurate as scan or dvbscan ever did! But please ignore that and see the szap bug instead. The error only happens with H, not with V, OK? My scan or scandvb program creates only lower cases polarization characters (v or h). I think the szap program only recognizes lowercase by design. In the console you will see the right frequency and the right symbol rate. But the polarization will be printed out as V (vertical) instead of H (horizontal). In other words: The bug is: szap cannot set equal the letter h with the letter H Regards Uwe P. S.: I solved the problem by a TCL-TK workaround, but it rather should be solved in the sourcecode, shouldn't it? So can someone reading this please fix that bug in the source code? ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb Regards Uwe hi uwe, yes, your predication is correct on the is does not happen at v or V for polarization. if you have a look at the sources, and also at my proposed patch - i am still waiting for your answer - szap just check[s|ed] for the h and if that is NOT present is assumes v. so everything else than a h or (with my patch applied) H will be treated as vertical. regards marcel ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] 2.6.21-rc1-git2 is incompilable
Uwe Bugla schrieb: Original-Nachricht Datum: Thu, 1 Mar 2007 18:31:25 +0100 Von: Marcel Siegert [EMAIL PROTECTED] An: linux-dvb@linuxtv.org CC: Uwe Bugla [EMAIL PROTECTED], [EMAIL PROTECTED], Slaby [EMAIL PROTECTED], [EMAIL PROTECTED], linux-kernel@vger.kernel.org, [EMAIL PROTECTED], Stephane Eranian [EMAIL PROTECTED], [EMAIL PROTECTED] Betreff: Re: [linux-dvb] 2.6.21-rc1-git2 is incompilable On Thursday 01 March 2007, Uwe Bugla wrote: Hi folks, trying to compile kernel 2.6.21-rc1-git2 is impossible. The broken module where the compiler gives up is /arch/i386/kernel/io_apic.c. Regards Uwe P. S.: Wouldn't it be a good idea to test at least error-free compilation before stuff like this is being published? hi uwe, according to kernel.org 2.6.21-rc2-git1 is an actual snapshot but, those are iirc auto generated. thus not being able to compile can happen. it also depends on your special .config best regards marcel p.s. wouldn't it be a good idea to check your mail recipients instead of sending mails to e.g. linux-dvb that do have no use with fixes of floppy drivers and or compile status in io_apic? :) dont take it too hard man... But I take it very hard as I want quality! Ciao Uwe hi, i can see your point - but then you shouldn't take snapshots of development environments. if you want quality take released vanilla versions of the kernel. they will normally be of that quality an enduser wants. regards marcel ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] 2.6.21-rc1-git2 is incompilable
On Thursday 01 March 2007, Uwe Bugla wrote: Hi folks, trying to compile kernel 2.6.21-rc1-git2 is impossible. The broken module where the compiler gives up is /arch/i386/kernel/io_apic.c. Regards Uwe P. S.: Wouldn't it be a good idea to test at least error-free compilation before stuff like this is being published? hi uwe, according to kernel.org 2.6.21-rc2-git1 is an actual snapshot but, those are iirc auto generated. thus not being able to compile can happen. it also depends on your special .config best regards marcel p.s. wouldn't it be a good idea to check your mail recipients instead of sending mails to e.g. linux-dvb that do have no use with fixes of floppy drivers and or compile status in io_apic? :) dont take it too hard man... ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] RFC: merge dvb_tuner_ops tuner-core second try
On Tuesday 27 February 2007, Markus Rechberger wrote:
Hi guys,
since I really want to get that xc3028 story done I propose to add
some changes to the dvb framework which would allow to support loading
tuner modules from v4l and dvb without having a real dependency of
each other.
The interface I aim at uses almost the same structure as dvb_tuner_ops.
So to point it out more clearly:
I'd like to replace or modify:
struct dvb_tuner_ops {
struct dvb_tuner_info info;
int (*release)(struct dvb_frontend *fe);
int (*init)(struct dvb_frontend *fe);
int (*sleep)(struct dvb_frontend *fe);
/** This is for simple PLLs - set all parameters in one go. */
int (*set_params)(struct dvb_frontend *fe, struct
dvb_frontend_parameters *p);
/** This is support for demods like the mt352 - fills out the
supplied buffer with what to write. */
int (*calc_regs)(struct dvb_frontend *fe, struct
dvb_frontend_parameters *p, u8 *buf, int buf_len);
int (*get_frequency)(struct dvb_frontend *fe, u32 *frequency);
int (*get_bandwidth)(struct dvb_frontend *fe, u32 *bandwidth);
#define TUNER_STATUS_LOCKED 1
int (*get_status)(struct dvb_frontend *fe, u32 *status);
/** These are provided seperately from set_params in order to
facilitate silicon
* tuners which require sophisticated tuning loops,
controlling each parameter seperately. */
int (*set_frequency)(struct dvb_frontend *fe, u32 frequency);
int (*set_bandwidth)(struct dvb_frontend *fe, u32 bandwidth);
};
with:
struct v4l_dvb_tuner {
/* wrapper */
void *priv; /* some privat data for internal use */
void *dev; /* v4l private data for tuner-core */
struct dvb_frontend *fe; /* dvb_frontend, for dvb only
drivers, internal use */
int (*ioctl)(struct v4l_dvb_tuner *dev, int cmd, int arg);
struct tuner_info info;
int (*release)(struct v4l_dvb_tuner *dev);
int (*init)(struct v4l_dvb_tuner *dev);
int (*sleep)(struct v4l_dvb_tuner *dev);
/** This is for simple PLLs - set all parameters in one go. */
int (*set_params)(struct v4l_dvb_tuner *dev, struct
tuner_parameters *p);
/** This is support for demods like the mt352 - fills out the
supplied buffer with what to write. */
int (*calc_regs)(struct v4l_dvb_tuner *dev, struct
tuner_parameters *p, u8 *buf, int buf_len);
int (*get_frequency)(struct v4l_dvb_tuner *dev, u32 *frequency);
int (*get_bandwidth)(struct v4l_dvb_tuner *dev, u32 *bandwidth);
#define TUNER_STATUS_LOCKED 1
int (*get_status)(struct v4l_dvb_tuner *dev, u32 *status);
/** These are provided seperately from set_params in order to
facilitate silicon
* tuners which require sophisticated tuning loops,
controlling each parameter seperately. */
int (*set_frequency)(struct v4l_dvb_tuner *dev, u32 frequency);
int (*set_bandwidth)(struct v4l_dvb_tuner *dev, u32 bandwidth);
int (*set_mode)(struct v4l_dvb_tuner *dev, struct
tuner_parameters *params);
};
tuner_parameters is an extended version of dvb_frontend_params
struct dvb_frontend_parameters {
__u32 frequency; /* (absolute) frequency in Hz for QAM/OFDM/ATSC
*/
/* intermediate frequency in kHz for QPSK */
fe_spectral_inversion_t inversion;
union {
struct dvb_qpsk_parameters qpsk;
struct dvb_qam_parameters qam;
struct dvb_ofdm_parameters ofdm;
struct dvb_vsb_parameters vsb;
} u;
};
vs:
struct tuner_parameters {
__u32 frequency; /* (absolute) frequency in Hz for QAM/OFDM/ATSC
*/
/* intermediate frequency in kHz for QPSK */
enum v4l2_tuner_typetype;
v4l2_std_id std;
fe_spectral_inversion_t inversion;
union {
struct dvb_qpsk_parameters qpsk;
struct dvb_qam_parameters qam;
struct dvb_ofdm_parameters ofdm;
struct dvb_vsb_parameters vsb;
} u;
};
for not breaking userspace we can use an internal converter for that
format just like:
#define V4L_OPS(i) ({ \
struct tuner_parameters __o; \
__o.frequency = i-frequency; \
__o.inversion = i-inversion; \
__o; \
})
this seems to be a good approach for hybrid devices
dvb only silicon tuners could still access dvb_frontend internally,
hybrid tuners have to avoid this since the structure since it wouldn't
be fully initialized.
So what do you guys think about that?
I already have some code which does this and it works fine.
So I'm looking for some feedback/suggestions here
thanks,
Markus
___
Re: [linux-dvb] gp8psk-dvbs2-091506 (genpix-usb kernel module patch)
On Friday 15 September 2006 17:57, m baufield wrote: I am submitting this patch. Its some modifications to the genpix-usb kernel module plus some fix ups. http://pastebin.ca/171690 - hi mbaufield, nice to see a patch that is based on my old dvb-s2 proposal. but, my proposal never got merged into the v4l-dvb repository, and won't be in future as it was superseeded by a solution that manu abraham provided within his multiproto patch. although that manus patch isn't applied yet. i do not know how long your patch will be available to others on the pastebin. normally you should attach or inline patches in/to your mail. best regards marcel pgpUhdoo3er0D.pgp Description: PGP signature ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] decoder frontend ioctls
Hi, can someone explain why DVB ApiV3 is not providing IOCTL's for getting e.g. the bitrate of the stream, resolution ect. ? some drivers do a /proc/bitstream interface or provide non dvbapi IOCTL's for this. so, if someone's going to use this info everything must be checked at user/application space. it would be more satisfied if i would have an IOCTL with -ENOSUP or -EINVAL instead of having a application which is capable to run on different systems and program everything especially for each system. regards mws
[linux-dvb] Re: decoder frontend ioctls
On Wednesday 07 July 2004 20:15, Marcus Metzler wrote: Marcel == Marcel Siegert [EMAIL PROTECTED] writes: Marcel Hi, can someone explain why DVB ApiV3 is not providing Marcel IOCTL's for getting e.g. Marcel the bitrate of the stream, resolution ect. ? What bitrate? Your are right, I was thinking e.g. about PES bitrates. Also on H by V resolution ect. In my special case i have got a /proc/bus/bitstream interface which is filled with data within the driver code, because the HW is supporting these data. On a second (but different Model) STB it is the same interface. While I do not know exactly if dvb-s cards can measure these things in hw or if there are registers which can be read on DVB-S i must/would have to implement it in a different way (Filter...). My suggestion was to have a api command to get a structure. if the driver supports to provide me with these info i would have a simplified interface to get this information. if a driver does not support these things - maybe caused by hw reasons - it still could provide the application with an -EINVAL or -ENOSUP reply. This prevents me and other people to implement the same stuff more than once. Isn't that what API's are for? To get standards and standard code only implemented ONE time? If not i may understand your reply to my question, but i am still at the opinion that maybe some people within linuxtv or this ml should not only think of DVB-S/C/T PC adapters. (Even Budget or FF) There must be a Standard API so software is able to run without re-coding for every machine. This is one of the reasons why i am using the API and talk to this ml. There are STB's that even do not NEED any of your API commands - but support them for compatiblity. They also would work great and fast (sometimes faster ) without the linux dvb api. But if there is hw supporting features these should be also implemented imho. Last but not least :) I sended an email to this ML some month ago concerning DVR playback on a WinTv DVB-S card. The driver is supporting this (even if it is broken mostly or just crashes) Sometime's i think that there is more conversation about implementing functionallity and also bugfixing or completing it - instead of doing so. People on this ml are thinking ( it did no post till now) about API V4, in my opinion - better try to get a complete and bugfree V3 :) All of these sentences may NOT be interpreted as personal treating but as constructive critics. Regards Marcel
[linux-dvb] Re: support diseqc-2.0 switches
Hi, i guess that you receive the operation not supported from the FE driver and not from andy DiSEqC Equipment you may use :) As Andrew told you already the STV0229B Frontend isn't able to react on a DiSEqC reply. It it the same reason like always - there is backwards compatiblity and manufacturing FE without these or other capabilities is cheaper. So why should somebody implement DiSEqC 2.0 functionallity into the FE Hardware - if you also can use the Switches with the 1.0 commands. Greetings mws Hi, I just spent a couple hours writing a program to handle diseqc parsing. I successfully sent the diseqc command (or I believe I did) and then set struct dvb_diseqc_slave_reply rep; memset(rep, 0, sizeof(rep); rep.timeout = 100; ioctl(fd, FE_DISEQC_SLAVE_REPLY, rep); I got operation not supported that's right, isn't it? I've got the stv0299 demodulator like you say. _J In the new year, Robert Schlabbach wrote: From: Andrew de Quincey [EMAIL PROTECTED] The hardware and APIs should already support it - Huh? AFAIK, the STV0229B has no means to receive any DiSEqC responses, and since that demodulator is used on most current cards, I'd say the hardware does NOT support it. Do you know of any DVB-S demodulator which supports bidirectional DiSEqC commands, and that is already used on receiver cards for PCs? Regards,« -- Robert Schlabbach e-mail: [EMAIL PROTECTED] Berlin, Germany -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject. -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Kernel OOPS
On Tuesday 09 March 2004 00:54, Oliver Endriss wrote: On Monday 08 March 2004 22:36, Robert Schlabbach wrote: From: Oliver Endriss [EMAIL PROTECTED] People have invested real money into these full featured DVB cards and just don't want to throw them away. Plus, there just isn't any reasonable alternative Full-featured ack. ;-) Full-featured cards are legacy hardware, they have no future. Thus, future looking development should be centered around _current_ hardware, and it has become quite obvious that so-called budget cards are a much better solution, because they are cheap and allow much more flexibility when it comes to handling the incoming data, simply because that's all done in software. Well, this has been discussed before. More than enough, imho. Even 'current' hardware will be outdated soon... Maybe exactly this this the most important thing. Think about not supporting or fixing any kind of driver because the Hardware may be outdated soon. Ever thought of ISA PlugPlay support in the Linux Kernel? Why it is still there? Haven't seen a board with ISA slots for a long time now - but - there are still people using the Linux Kernel on machines which offer isa slots and isa plug'n'pray :) I upset about myself not to have enough knowledge for developing kernel driver and/or TS/PES conversions. Maybe i have to improve this someday :) cu mws -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Kernel OOPS
On Friday 05 March 2004 12:36, Johannes Stezenbach wrote: Holger Waechtler wrote: Johannes Stezenbach wrote: The problem is that the av7110 hardware does not support TS playback. The driver tries to work around this by remuxing the TS into PES and feeding PES to the hardware. IMHO this code should be dropped rather than attempted to fix. Remuxing should be done in user space. VDR does the right thing. calling the PES unpacking process a 'remuxing' is kind of flattered, Right, it is actually demuxing and PES packaging. not? Forcing everybody to misuse the lowlevel-API instead of highlevel access just because the av711x driver is broken has the unlovely side effect that on well-designed hardware that can eat PS and TS directly the code will still do all the protocol handling and bit-twiddling on the host processor, the dedicated hardware will run idle. I don't know what you mean. Usually you advocate tiny drivers that just make the capabilites of the hardware available to userspace. Sure, it would be cool if VDR would be changed so it supports other hardware just as good as the av7110 cards. But IMHO VDR should use PES playback on av7110 cards, and TS playback on hardware that support it. Doing TS-PES conversion in the driver is wrong. The Avia processor and all modern STB CPUs can process multiplexed streams directly. Some of the cheaper variants of modern STB chips don't process TS from RAM, just from the frontend inputs. Johannes Ok i am able to understand this situation and all of the problems. Please take the next sentences as my thinkin of the whole situation :) why is there a need for any kind of a dvb api when you have to implement driver missing features in your software? on my point of view it looks like - if my application runs e.g. on a DBOX2/Dreambox/Whatever Linux running STB do nothing, if it runs on a PC check for driver version / hardware revision ect. and implemented hardware dependend stuff into the application. In this special case an API is a kind of software stuff to simplify coding and that a developer of an application must have understanding in DVB / Linux but not Driver Coding So if you started someday somehow a development of TS Playback capabilities via the dvr device without having real support for this on the hardware side - you should fix this. Otherwise take this feature away, and be happy with postings and claims over much applications no longer working. Am i totally wrong ? :) cu mws -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Kernel OOPS
On Friday 05 March 2004 13:43, you wrote: Ok i am able to understand this situation and all of the problems. Please take the next sentences as my thinkin of the whole situation :) why is there a need for any kind of a dvb api when you have to implement driver missing features in your software? on my point of view it looks like - if my application runs e.g. on a DBOX2/Dreambox/Whatever Linux running STB do nothing, if it runs on a PC check for driver version / hardware revision ect. and implemented hardware dependend stuff into the application. In this special case an API is a kind of software stuff to simplify coding and that a developer of an application must have understanding in DVB / Linux but not Driver Coding So if you started someday somehow a development of TS Playback capabilities via the dvr device without having real support for this on the hardware side - you should fix this. Otherwise take this feature away, and be happy with postings and claims over much applications no longer working. Am i totally wrong ? :) cu mws Add. I missed something - of course all it is depending on open source and nobody can be taken under pressure to fix it. But it would satisfy lots of people if it would be fixed, cu mws -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
