[mythtv] diseqc

[Yeasah Pell]

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 
artificial.

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.