yeasah at schwide.com
Wed May 24 19:33:19 UTC 2006
The DVB DiSEqC code in myth has some shortcomings that make it difficult
to use for my hardware. I'd like to have a quick discussion about what's
wrong with it, and the best way to improve the state of things.
DiSEqC devices form a network of connected gadgets, which do various
things. In practice, it's pretty much limited to switches and motors.
There's pretty good support for various switches in MythTV (including
odd "legacy" switches I've never heard of), but there's absolutely no
support for more than one DiSEqC device per card. There was a patch a
while back that added some special case motor + switch combinations, but
at this point one of those has been hijacked for some strange 10
position switch, and the other is unused.
The motor+switch stuff in the patch wasn't great anyway -- there's 2
types of motors (3 if you count no motor) and a slew of switch types, so
you'd need 3x the number of diseqc types just to represent all the
various permutations of motors and switches. The patch just added one
particular switch type along with motors.
I would propose that instead of trying to shoehorn everything into a
single dvb_diseqc_type field in the capturecard table, it be broken up
into two types -- say by adding a new dvb_rotor_type field (none,
diseqc, and diseqc usals). This would allow the representation of the
full spectrum of rotor and switch combinations at least.
IIRC, previously the various switches were selected by a "DiSEqC Port"
value set by the user, which was written into the diseqc_port field of
the cardinput table. It looks like recently this was changed to take the
port number directly from the card input ordinal number -- please
correct me if I'm wrong about this. The general idea seems to be to
populate the setup UI with a number of inputs based on the diseqc
configuration selected, and then number the ports accordingly. For the
motors, 20 and 50 positions are established, though the 50 limit is
I believe this is a bad idea, and not just because it complicates motor
+ switch situations. It also makes it difficult for somebody to change
the physical diseqc port assignment should they want to do so at some
point. Anyway, if you were to simply pre-populate the input list with
the number of motor possibilities * the number of switch possibilities
(the most obvious way to extend this system), it would be really
difficult to set up, since you normally have a very sparse set of
positions and ports that are useful.
I think it's much better to put the port field back into the UI. Also,
the non-usals motor actually takes its motor index from the diseqc_port
field right now, which again seems nice enough until you have a switch +
motor situation. I think it should again be explicitly configured by
taking its position from the diseqc_pos field (so that always represents
a motor position) directly, and having the user input the position --
again, nobody wants all the positions anyway.
I have already done some of this work, but I'd like some feedback as to
whether this is perceived as being generally useful, and if so, whether
this seems like a good approach.
More information about the mythtv-dev