Jason BARSTOW wrote: >> Do you have distinct groups of layers, mixers and encoders? Otherwise you > would >> have one (primary) 'screen' entity with multiple outputs for multiple > displays (screens). > > I have multiple screens, each screen has its own distinct set of layers. > The encoder and mixer aren't currently exposed - so each screen has an > implicit single encoder and mixer. > So, I guess I'm really trying to decide how best (to what degree) to expose > configuration of the screen's encoder/mixer. > Hooking the base layer resizing to trigger a mode change is a simple way > that provides behaviour consistent with fbdev type implementations. > But this would only provide for resolution change and means that the base > layer is always aligned to the mode - i.e. is always 'fullscreen'. > I think this is why you suggest using the encoder API since that should > allows more flexibility...
Yes. >> Please look at the encoder and maybe mixer configuration instead, letting > layers >> be independent viewports mixed in another coordinate system (mixer > dimension) for >> display via one of the encoders. > > This is where I become a little unstuck. It's not clear to me with the > current interfaces how the client should specify the mode. > I think it's something like this: > > - Establish available encoders > IDirectFBScreen.GetEncoderDescriptions( FBScreenEncoderDescription ) > > - Configure screen encoder (PAL, NTSC etc) > IDirectFBScreen.SetEncoderConfiguration( 0, DFBScreenEncoderConfig ) > > - Configure screen output to use the encoder and connector. > IDirectFBScreen.SetOutputConfiguration( 0, DFBScreenOutputConfig ) > > In FBScreenEncoderDescription, DFBScreenEncoderType provides for either > DSET_CRTC or DSET_TV. > In DFBScreenEncoderConfig, DFBScreenEncoderTVStandards provides DSETV_PAL, > DSETV_NTSC etc. > > So, I think the client might set an encoder of type DSET_TV to say output > DSETV_PAL (which will implicitly define resolution and frequency). > Is that correct? Yes. > What is DSET_CRTC? Is it 'cathode ray tube'? For type DSET_CRTC how are > timings (resolution and frequency) specified? Yes, it's for CRT controllers, but apart from the FBDev system there's no use of it I think. The timings are not specified, but are taken from /etc/fb.modes :( > Likewise, how would HD modes be selected? - e.g. 720p etc? Using DSETV_DIGITAL with DSOR_1280_720 and DSESM_PROGRESSIVE. > It looks like there should be an equivalent entry to > DFBScreenEncoderTVStandards where the mode is fully configurable. > e.g. DFBScreenEncoderMode, which is a struct containing timing related > fields - perhaps just "width,height,frequency" > (which is more or less what you are suggesting I think). I thought the resolution would be variable, but I can only find the few fixed resolutions for HD. > Of course this 'generic device' might not actually be a CRT or TV - so > perhaps it would be best to add a DSET_GENERIC to DFBScreenEncoderType. > Or would DSET_UNKNOWN be sufficient here? DSET_NONE=0 for setting no specific type would sound better, but UNKNOWN=0 is already there and both in one enum might be confusing, especially because all NONE flags in DirectFB map to zero. > So a client can select an encoder of type DSET_GENERIC (or DSET_UNKNOWN) > and then provide resolution and frequency using DFBScreenEncoderMode. > DFBScreenEncoderDescription should expose support for variable modes > (timings) perhaps in the DFBScreenEncoderCapabilities field (e.g. > DSECAPS_MODE) Yes, that should be added. >> Does DSETV_DIGITAL plus resolution, scanmode etc. suffice? > Instead of adding new type to DFBScreenEncoderType? Perhaps... > It may be digital or analog, LCD panel, VGA etc - so a new > DFBScreenEncoderType entry of 'GENERIC' might be useful as a catch-all. Yes, better than UNKNOWN. > BTW, it seems the client can specify DFBScreenOutputSignals in > SetEncoderConfiguration() and SetOutputConfiguration() - why is this? The first defines the signal(s) to generate at the encoder, if more than one is possible. The second defines the signal(s) that the output should use. Imagine one encoder with RGB, YC and CVBS signals, a Scart output with RGB/CVBS switching and another output for YC. -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
