Developer Forum

Hallo Thomas,

thank you for your contribution. However, I'm against applying it.



Why do you think that's impossible? There's a userspace implementation
in Enigma2.


That statement is not true, because you have to configure Unicable LNBs,
which you do using dvb-scr-setup.c.

Regards,
Andreas
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/

Hallo Thomas,

thank you for your contribution. However, I'm against applying it.



Why do you think that's impossible? There's a userspace implementation
in Enigma2.


That statement is not true, because you have to configure Unicable LNBs,
which you do using dvb-scr-setup.c.

Regards,
Andreas
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/

Hallo Thomas,

thank you for your contribution. However, I'm against applying it.



Why do you think that's impossible? There's a userspace implementation
in Enigma2.


That statement is not true, because you have to configure Unicable LNBs,
which you do using dvb-scr-setup.c.

Regards,
Andreas
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/

Hallo Thomas,

thank you for your contribution. However, I'm against applying it.



Why do you think that's impossible? There's a userspace implementation
in Enigma2.


That statement is not true, because you have to configure Unicable LNBs,
which you do using dvb-scr-setup.c.

Regards,
Andreas
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/

Hallo Andreas,

Am 10.01.2011 um 14:09 schrieb Andreas Oberritter:



I think the kernel implementation would be superior for two reasons:
- There are some timing requirements regarding the 14/18V transitions and the DiSEqC message which could perform better directly from the frontend code,

- In many TV recording applications there is no support for SCR and it would be harder to implement in these. For VDR, there is a patch which is difficult to configure and has some technical limitations. In MythTV and XMBC I could not find any support for SCR. Their Wiki pages or forums say, that there are no plans for Unicable support as it would take huge changes.


Sure, you have to configure Unicable LNBs as you have to configure for example Universal LNBs. So the viewer software has to be aware of your DVB setup's parameters. If you want to have a configuration menu in the viewer software, this software only needs to send a simple ioctl message to the frontend to configure Unicable. If you want to use Unicable with viewers that do not support it, you only have to set your parameters at boot time using dvb-scr-setup.c.

That way, they are also a bit more protected against unintentional changes. In a Unicable system, all participants have interferences if there is one participant using bad settings. So if you start a DVB viewer which is badly or not yet configured, all other participants are disturbed. If you configure your Unicable system using e.g. an init-script, it is impossible to disturb anyone by starting some "Non-Unicable" software.

This can be compared to the setup of serial ports, I think. As far as I know, there is a setup utility to have the parameters set (probably at boot time), afterwards you start the actual application.

Regards,
Thomas

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/

Unless there's proof, I won't believe that. We're not talking about
nanoseconds, but milliseconds, and it's about setting registers of slow
I2C devices. The same timing requirements are valid for each and every
backwards compatible DiSEqC sequence, which is the most common setting.


Many of these applications didn't or don't support DiSEqC 1.1
(uncommittted switches) or DiSEqC 1.2 (rotor commands) or USALS. Still,
we don't put this logic into the kernel to make their life easier. Don't
add unneeded complexity to the kernel.

Of course, one could decide to start a reusable library to take care of
that stuff. Honestly, I don't know whether such a library exists today.

If you find the patch was simple enough to be applied to the kernel, it
must be as simple to patch your favourite application, even in a
platform independent way (not taking into account the required changes
to the UI, which have to be done anyway).

Regards,
Andreas
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/

Am 10.01.2011 um 16:54 schrieb Andreas Oberritter:


I think this is the point we are talking about and I understand the feature might not be critical enough to justify a kernel implementation.

Regards,
Thomas--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/