Carsten Juttner wrote: > Felix Domke wrote: >> standard would use the default standard. Dual-Mode-Frontends would >> default to either DVB-S, oder -T or whatever. There could be a tool to >> change the mode. DVB-S2 would simply be not possible without the new >> FE_SET_STANDARD, as the default would be DVB-S. > You haven't adressed the issue Rainer had, yet. Should a dual-mode > (meaning that it can EITHER operate in one OR the other mode) frontend > be abstracted away as 2 distinct frontends (frontend0..fronend1)? One frontend. With my proposed "locking method" (see below), you have to get the current standard (!= modulation!) once, then poll the status. Sure, a "standard" field in the frontend structure would be great, but it isn't there, and all methods of adding one would raise more backward compatibility issues... > The advantage of having 2 logical devices in the system is that older > applications would have to know nothing about switching between the > modes, they would just open the correct device and check its type and if > the ioctl is unable to retrieve information it would simply return an > error. A simple userspace tool can switch the mode in advance, before starting the legacy application. > The disadvantage is that the user might believe he can use both of them > at the same time (this raises questions, causes traffic on mailing lists > and developers spend valuable time answering them). Not only the user, but also the application. Telling an application to use only one of two available frontends *at a time*, i guess, is as complicated (or even more) as adding the FE_SET_STANDARD ioctl. > The advantage of having one logical device is that the application > could properly describe it in a GUI (with f.ex. a spin box) and that > the user knows there is only one device. Yes, exactly. This is by biggest concern over the "two frontends"-approach: Telling the application which combinations are possible is nearly impossible. Think of a DVB-S/S2/T combination, plus two -S-only frontends on one adapter: Which, backward compatible, bitfields could ever describe this scenario? > The disadvantage and also Rainer's concerns were that this puts the > issue of having to determine which mode is active on the application. If > for example one application is displaying the current status in > read-only mode and another application is able to write to the frontend, > this could cause the first application to get out of sync with the > frontend because - if using the old ioctls - it would not be able to > tell just from the struct what mode the frontend is operating in and > would have to use both FE_GET_INFO/FE_GET_FRONTEND-ioctls to determine > the type of the frontend and the mode of the struct that is returned. Having two frontends has the same problem. Imagine one Application is monitoring logical frontend0 (for example, the DVB-T part), and another one is tuning on frontend1 - what should happen? FE_SET_STANDARD should fail with -EBUSY when the frontend is opened, even read only. > Another problem is that, if for example a dual-mode device supports both > DVB-S and -C there would be no "default compatibility mode" that the > device could enter on startup, so the burden would be put on the user to > decide (probably by using a module parameter). Again, a simple userpace tool should do it. Sure, it's one more thing for the user to learn, unless he uses an application which does the FE_SET_STANDARD... > Of course all of this is pretty academic unless we really do have those > devices in widespread use. Sure :) Felix
