On Fri, 2012-04-20 at 13:49 +0300, Grazvydas Ignotas wrote: > On Fri, Apr 20, 2012 at 11:38 AM, Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote: > > On Thu, 2012-03-29 at 02:45 +0300, Grazvydas Ignotas wrote: > >> VENC type (composite/svideo) doesn't have to be fixed by board wiring, > >> it is possible to provide both connectors, which is what pandora does. > >> Having to recompile the kernel for users who have TV connector types > >> that's don't match default board setting is very inconvenient, especially > > > > You don't have to recompile the kernel, you could just set the venc type > > in the board file depending on a boot parameter. > > > >> for users of a consumer device, so add support for switching VENC type > >> at runtime over a new sysfs file venc_type. > > > > I really dislike adding new custom sysfs entries for omapdss, and I'd > > like to avoid them if at all possible. > > Well some panels already have custom attributes, and venc could be > considered as special panel type, so if it's allowed for panels, why > not allow it for venc? It's not really about "allowing". It's just that each new sysfs file is a new non-standard custom API to userspace which we need to support until the end of time. Adding new sysfs files carelessly will cause a nightmare for me in the future, so by default I'm against new sysfs files =). > > Do you need to change the venc > > type during runtime, or is it enough that it can be set during boot? > > We need this on runtime, otherwise it causes several issues: > - reboot is required to change the setting, although there is no > technical reason to really require it. This punishes users who want to > try both settings or have both TV types (with a portable device this > may sometimes happen). > - having to provide a way for users to change this in kernel boot > arguments. Note that many pandora users don't know how to handle boot > scripts, so a bootloader menu of some sort would be needed or ability > to edit u-boot environment from Linux, both of which would be > needlessly complicated solutions. Ok. Sounds like we need to have dynamic configuration. I'll review the patch. Tomi
Attachment:
signature.asc
Description: This is a digitally signed message part
