Doing this with enums makes it very inflexible.
Agreed.
IMO the resolutions and scan frequencies should be specified via a struct
of somekind. Maybe a full blown video timing structure like the (currently
internal) VideoMode structure. Then it would be a matter of calling some
method to enumerate the supported modes.
Why invent one, it is already defined in linux/fb.h and it then makes it
easy to use directly in the fbdev system, or in a hardware driver that
wants to defer to the framebuffer to do an actual mode change. At least
you then have the choice to fiddle with the HW yourself or not depending
on the rest of your driver architecture. At the very least it should be
trivial to go from a DirectFB timing structure to the FB Var structure.
I think we should leave the TV stanrdards to only indicate chroma
encoding. That means they really only concern CVBS and Y/C signals. We'd
just need to add a "few" of them to cover everything.
That certainly makes sense to me, I am very unconvinced about defining
HD modes in this enum.
Another thing you do need to control somewhere is the format of component
outputs, i.e. RGB or YPrPb.
SECAM?
What SECAM variantts are there?
None that I am aware of.
-stephen
_______________________________________________
directfb-dev mailing list
directfb-dev@directfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
