Jason BARSTOW wrote: > Hi all, > > I have a question about setting screen modes - and exactly how a driver is > expected to handle this in a multiple screen system.
In DirectFB a 'screen' is a logical group of 1-n layers and 0-n mixers, encoders or outputs. While you have one or more screens (displays) connected via different outputs and/or encoders, it is one 'Screen' in DirectFB, as long as components are movable or sharable within the logical group, e.g. layers and mixers assignable to different outputs/encoders or Video+OSD on Main Output and just the Video Layer on Sub Output. > As far as I can tell, setting a surface on the primary layer should > trigger a screen mode change > ( the system drivers (eg. fb,sdl) have entries for primarySetRegion() > and the implementations for these appear to make mode changes. ) It's a weakness of these APIs (fbdev, sdl) and hasn't been specified in DirectFB for a long time either. Now think of a 'mixer' with a certain pixel dimension plus 'encoder' taking images at mixer's dimension, to output at a certain resolution, signal type etc. 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). > From the users point of view there is DSCID_PRIMARY which can be used to > configure the primary layer. I believe from the cores point of view this is > always the first layer in the system. DLID_PRIMARY is the first layer registered by the system module or graphics driver. > 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. > 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. > I'm thinking that I could add mode change support by extending my existing > generic layer SetRegion() function - when this is called for the first > layer in a screen, then I would set the new mode for that screen to the > layer (region) size. 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. Does DSETV_DIGITAL plus resolution, scanmode etc. suffice? > Can anyone tell me, > - how does directfb choose a layer to become the primary - is it > always layer '0'? The primary layer is by default the layer with id 0, but with the option "primary-layer = <n>" the application sees layers with id 0 and n swapped. > - in which case, would allocating the first layer in the first screen > as the implicit primary as I've suggested be valid? > - furthermore, would allocating the first layer in every screen as > the 'mode defining layer' be correct and consistent (PRIMARY, SECONDARY, > ... )? Not applicable :) 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). -- 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
