Re: PATCH: extra switch for zap (developers?)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Uwe Bugla wrote:
> Am Freitag, 27. Juli 2007 04:27:59 schrieben Sie:
>> P. van Gaans wrote:
>>> Uwe Bugla wrote:
>>>> Am Donnerstag, 19. Juli 2007 02:29:34 schrieben Sie:
>>>>> Uwe Bugla wrote:
>>>>>> Am Mittwoch, 18. Juli 2007 06:03:41 schrieb P. van Gaans:
>>>>>>> I don't call myself a programmer (I've never seen any C guide), but
>>>>>>> somehow I figured out how to add an extra switch to tzap to make it
>>>>>>> print the status in (human-readable) decimal instead of hex. It is
>>>>>>> attached. It would be really nice if this would make it into the
>>>>>>> dvb-apps on linuxtv..
>>>>>>>
>>>>>>> Talking about that, could anybody tell me the minimal and maximal
>>>>>>> and/or
>>>>>>> possible values for status, signal, snr, ber and uncorrected? If I
>>>>>>> would
>>>>>>> know them I could try to make the numbers more human-readable (eg
>>>>>>> signal
>>>>>>> ranging from 0 to 99 or so).
>>>>>> Could you please redo that:
>>>>>> - in patch format (=only the additions)
>>>>>> - equally for tzap, czap, szap and femon?
>>>>>>
>>>>>> Thus everybody could take advantage from that idea.
>>>>>> Would be a pleasure for us all if you did!
>>>>>>
>>>>>> My idea for further enlargement (a quite old idea of mine):
>>>>>> route the human readable numbers into a speech recognition engine
>>>>>> (festival) to make them auditable and thus real usable for DVB-S dish
>>>>>> tuning f. ex.
>>>>>>
>>>>>> Note: If the DVB-S dish is far away from the machine (card), auditable
>>>>>> signals are necessary.
>>>>>>
>>>>>> _______________________________________________
>>>>>> linux-dvb mailing list
>>>>>> linux-dvb@xxxxxxxxxxx
>>>>>> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
>>>>> In patch format.. Oh please.. I have no idea how to produce that! I
>>>>> installed xxdiff, it perfectly shows what I've changed but I don't see
>>>>> an option to save it to a patch file!
>>>>>
>>>>> You're lucky I've got a satellite dish so I should also be able to
>>>>> patch szap and femon. I'll also produce a patched version of czap but
>>>>> my cable card is not installed ATM and I don't feel like doing so
>>>>> (cable provider is crap) but I'll probably get someone else on this
>>>>> list to test it.
>>>>>
>>>>> Please do not try to add the switch yourself without asking me if I'm
>>>>> still working on it. Nobody needs double work.
>>>>>
>>>>> If somebody can tell me how to produce the so much wanted .diff files
>>>>> I'll start working on it.
>>>> A. Take the latest kernel patch (i. e. 2.6.21.1) as an example.
>>>> B. format is as follows:
>>>> --- a/(file to be changed)
>>>> +++ b/(file to be changed)
>>>> @@ -(starting line number),(total number of lines starting from the
>>>> beginning line before the change) +(starting line number),(total
>>>> number of lines starting from the beginning line after the change)
>>>> (3 context lines starting with a space)
>>>> (additions start with plus)
>>>> (deletions start with minus)
>>>> (3 context lines starting with a space)
>>>>
>>>> If this explanation still is too abstract, have a look at the example
>>>> again.
>>>> Don't forget to test the patch!
>>>> No fuzz factors, no rejections please.
>>>> For testing purposes keep the original file to be patched in a
>>>> separate directory please.
>>>> Now please give it a try - for sure you gonna make it!
>>> I've got an idea of how the .diff is constructed, but I simply refuse to
>>> write them by hand. I've bought a computer NOT to do any more boring
>>> repetitive work ;-).
>>>
>>> diff -urN oldfile.c newfile.c > lolwat.diff appears to work luckily.
>>>
>>> Tzap was patched already.
>>> Szap patched, compiles, tested and OK.
>>> Czap patched, compiles without errors, untested because I hate my cable
>>> provider and the box I would have to install the cable card in is really
>>> noisy and unstable. Whoever wants to test: please report results, czap
>>> looks a little different from szap and tzap but I'm pretty certain it'll
>>> work straightaway. I assume this is OK, you couldn't expect all linuxtv
>>> developers to own cards for all DVB-systems anyway..
>>> Femon patched in a different way: Femon already has a "human readable"
>>> switch, I just made BER and uncorrected show up as decimal instead of
>>> hex in human readable mode. Adding another switch sounds pointless to me.
>>>
>>> The numbers/output seem to differ between devices and between szap and
>>> tzap greatly so for now I'm not going to try to make them more
>>> human-readable because of the possibility of breaking something.
>>>
>>> Everything attached.
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> linux-dvb mailing list
>>> linux-dvb@xxxxxxxxxxx
>>> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
>> There was some confusion cause of Uwe, but will my switch ever make it
>> to the dvb-apps on linuxtv? Or is there something wrong with it?
> 
> I did not want to cause any confusion at all, but I just transformed your work 
> into a patch format that is expected everywhere in the linux world if you 
> want your stuff to be merged.
> 
> As it was refused as a whole (patched dvb-apps) I decided to resend it to 
> Christoph Pfister CCing you.
> 
> Everybody's waiting for Christoph Pfister now.
> 
> Cheers
> 
> Uwe
> 

Yes, I saw that mail a little later after my reply was already sent.

It seems the "patch format" is just all my diff files following up each 
other in one file? If that's the expected format, good to know.

_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[Index of Archives]     [Linux Media]     [Video 4 Linux]     [Asterisk]     [Samba]     [Xorg]     [Xfree86]     [Linux USB]

  Powered by Linux