[linux-dvb] Re: libdvb: is this a bug

["Sven Severus" <sseverus@debitel.net>]

Hello mailinglist,

unfortunately my last posting was not readable, because
my email client produced something in html format with
white characters on white background :-o.
Sorry for that. This time it's text format.

Today I found the new release 0.2.3 of the libdvb on
http://www.metzlerbros.de/mbros/dvb/.
A diff to to the 0.2.2 release showed the bugfix I proposed.
Thanks to Marcus Metzler.

Sven Severus

=============================================

> Hello newsgroup,
>
> I am not sure, but I think I found a bug in libdvb (0.2.2).
>
> Frank Verlinden reported the following problem in a posting dated 3 Mar
2003
>
(http://www.linuxtv.org/mailinglists/linux-dvb/2003/03-2003/msg00009.html):
> > After loading the Convergence or the Metzler DVB drivers the n-tv screen
> > is showed. When starting Tuxzap and trying to switch to an FTA channel
> > the screen becomes blank. With the Convergence driver, it is still
> > possible to switch with szap.

> I had the same problem, but unfortunalety Frank did not continue the
thread,
> so I tried to find out the reason and a solution by myself. Let me now
report
> my results:
>
> In source DVB.cc is a function set_diseqc_nb. Its purpose is to
> assign proper values to the six bytes and the length attribute of
> the struct dcmd, used as parameter for the frontend API function
> FE_DISEQC_SEND_MASTER_CMD later on.
> Here is a part of the C code: ------------------------------
>     dcmd.msg[3]=0xF0 |
>                          ((nr * 4) & 0x0F) |
>                          (tone ? 1 : 0) |
>                          (voltage ? 2 : 0);
> ------------------------------------------------------------------------
>
> According to the DiSEqC specification bus_spec.pdf (found at
> http://www.eutelsat.com/satellites/4_4_5.html), chapter 8.3
> "Command Byte" and chapter 9.1 "Write Port Group", and
> slave_microcontroller_spec.pdf, chapter 7.2 "Committed
> Control Pins", dcmd.msg[3] is the data byte in the
> "Write N0" command (hex code 0x38, "write to port group 0
> (committed switches)").
> The meaning of the least significant bit in this data byte is:
> 1 <=> "High L.O. frequency selected".
>
> Now lets look at what happens if tuxzap switches to a transponder
> in the high band area:
> In function DVB::SetTP tone is properly set to SEC_TONE_ON,
> but unfortunately the enum type of tone is:
> ------ linux/dvb/frontend.h ---------------------------------
> typedef enum fe_sec_tone_mode {
>         SEC_TONE_ON,
>         SEC_TONE_OFF
> } fe_sec_tone_mode_t;
> ---------------------------------------------------------------------
> (see also "Linux DB API Version 3", V1.0.0 pre1,
> chapter 2.1.7 "SEC continuous tone")
> That means, that "tone" has _zero_ value and "(tone : 1 : 0)"
> evaluates to 0, resulting in the least significant bit in
> dcmd.msg[3] NOT set in this case.
> This is a contradiction to the eutelsat specs.
>
> I patched the expression to: ((tone == SEC_TONE_ON) ? 1 : 0),
> and a very similar piece of code in function set_diseq the same
> way. This is much more robust coding, and it worked properly.
>
> =============================================
>
> Is this a bug?
> I am doubtfull, because only one posting reported this problem.
> I would highly appreciate a statement of Marcus Metzler.
>
> Thanks in advance for any answer.
>
> Best regards,
> Sven Severus



-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.