Hi Denis,
as always, thanks for the detailed reply.
> With one layer (fb ioctls) limited to pixel aligned fullscreen output (no
DLCAPS_SCREEN_POS/SIZE)
> and no mixers, encoders or outputs, the fbdev system module implies
encoder settings (mode
> switching) to keep the (virtual) mixer's dimension aligned with the new
layer size AND output
> format (display mode).
OK, that's consistent with how I understood it.
>> In my system, I have a "N screen x M layer" system and *all* layer
handling
>> is done by the gfx driver - I dont expose an explicit primarySetRegion;
so
>> the primary layer is treated no differently to any other layer.
> So you have one layer driver implementation for all planes, that's fine.
Cool.
>> For this reason, I currently expect modes for all screens to have been
set
>> as required before the app is run, and resizing the primary layer just
>> moves it within the existing mode.
> That has been the behaviour on STB like platforms, most likely with the
encoder
> settings and mixer dimensions fixed to 720x576 or 720x480.
> It's also the correct behaviour, as opposed to the fbdev implementation
which
> suffers from cruft sitting between CoreLayer API and the hardware.
OK - that's good to hear - it does feel cleaner, more flexible and
consistent this way.
> 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...
> 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?
What is DSET_CRTC? Is it 'cathode ray tube'? For type DSET_CRTC how are
timings (resolution and frequency) specified?
Likewise, how would HD modes be selected? - e.g. 720p etc?
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).
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?
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)
> 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.
BTW, it seems the client can specify DFBScreenOutputSignals in
SetEncoderConfiguration() and SetOutputConfiguration() - why is this?
Regards,
Jason.
_______________________________________________
directfb-dev mailing list
directfb-dev@directfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
