GOBE SCOTT/01/02DOC!SpFVSVERMVerMWORDWord ProcessingGRFXGraphicsPROT PagedRootPartPAGEPagePartSETMSetMPENMPenMSTYMPRPMPROPArrwProPPROPFColwtwProPPROPFTraProPPROPFTra?ProPPROPLSpa?ProPPROPPAlgProPPROPPAlgProPPROPPColwtwProPPROPPEN NORM DefaultProPPROPPENzProPPROPPENz?ProPPROPPIndProPPROPPLabProPPROPPLefProPPROPPRigProPPROPPTraProPPROPPTra?ProPPROPSpaAProPPROPSpaBProPPROPTColwtwProPPROPTFacProPPROPTFacProPPROPTFacProPPROPTFacProPPROPTFon Swis721 BTRomanProPPROPTFon Swis721 BTBoldProPPROPTFonDutch801 Rm BTProPPROPTSizProPPROPTSiz ProPPROPTSiz ProPPrpMSTYPStyPSTLTSTYLSTYL2BasiDefaultPTAB  PtaBPTABPtaBSTYLSTYLSTYL"BasiText BackgroundPTAB PtaBPTABPtaBSTYLSTYLSTYL BasiPTABPtaBPTABPtaBSTYLSTYLSTYL BasiPTAB PtaBPTAB  PtaBSTYLSTYLSTYL BasiPTABPtaBPTAB  PtaBSTYLSTYLSTYL BasiPTABPtaBPTAB  PtaBSTYLSTYLSTYL BasiPTABPtaBPTAB PtaBSTYLSTYLSTYL BasiPTABPtaBPTAB PtaBSTYLSTYLSTYL BasiPTABPtaBPTAB PtaBSTYLSTYLSTYL0BasiPTABPtaBPTAB PtaBSTYLSTYLSTYL/ BasiPTABPtaBPTAB PtaBSTYLSTYLSTYL BasiPTABPtaBPTAB PtaBSTYLSTYLSTYL BasiPTABPtaBPTAB PtaBSTYLSTYLSTYL BasiPTABPtaBPTAB PtaBSTYLSTYLSTYL BasiPTABPtaBPTAB PtaBSTYLSTYLSTYL BasiPTABPtaBPTAB PtaBSTYLSTYLSTYL BasiPTABPtaBPTAB PtaBSTYLSTYLSTYL BasiPTABPtaBPTAB PtaBSTYLSTYLSTYL BasiPTABPtaBPTAB PtaBSTYLSTYLSTYL BasiPTABPtaBPTAB PtaBSTYLSTYLSTYL BasiPTABPtaBPTAB PtaBSTYLSTYLSTYL BasiPTABPtaBPTAB PtaBSTYLSTYLSTYL BasiPTABPtaBPTAB PtaBSTYLSTYLSTYL BasiPTABPtaBPTAB PtaBSTYLSTYLSTYL BasiPTABPtaBPTAB PtaBSTYLSTYLSTYL"GRFX GR DefaultPTABPtaBPTAB  PtaBSTYLSTYLSTYL2ParaBodyPTABPtaBPTAB PtaBSTYLSTYLSTYL2Para WP DefaultPTAB PtaBPTAB  PtaBSTYLSTYLSTYLpParaPTABPtaBPTAB PtaBSTYLSTYLSTYL ParaPTABPtaBPTAB PtaBSTYLStlTStyMSheet 1DDFBBDD4 1BOFpkoKkokoGNOLprinterLOOBbitmapGNOL orientation RTSC page size Letter.4MegTOLFscalingBTCER paper_rectDFDGNOLunitsTCERprintable_rectAAD@>DLOOBfirst upSELMGRFXWORDWORD WORDWORDWORD!5!8WORDWORD!+!0WORD!7!8WORD WORD WORD !>!FWORD BCWORD WORDGHWORD WORD66WORD SelMLINKLinKPARM WORD^GRFXPROTPAGEWORDWORDWORDWORDWORDWORDWORDWORD^PARTWORDwp++?9?9par+            1=>CD  OP Q i j: 0        4 Q c x {w  %   7 8 9a ( .F " :   2 N  n&    !    ! 1 H _ w+       P      - .) W   & A %% J4 ~( S ( ! * ] e/ : 0 g e6  j 1 72 i3   ^ M [   49 m n o ^      eb "4 a "4 ( )      G H         ^        (  , I  i     G H   h !C !E!F+* !q !r !s ! " " # #$ $C $D % %  & & ' ' ' ( ( )l )m  )y` * * + ,% ,&2 -X -Y . . /{ /| 0C 0D  1M 1N 2B 2C 2[ 3 4 4Y 5 5 6 6 6 6 7~ 81 82 83; 8n 8o 9]B :V :M ;BR ;a ; ;; <1Z <0 < <> <- =' =E =F =_P =S > > > ? ? ? ?' ?( par-txt+ Rudolf's BeOS Matroxdriver design considerations V0.2 27/3/2003  The setmode mode.flags. The setmode command mode.flags will be further expanded. The BeOS standard flags are: (see accelerant.h) enum { /* mode flags */ B_SCROLL = 1 << 0, B_8_BIT_DAC = 1 << 1, B_HARDWARE_CURSOR = 1 << 2, B_PARALLEL_ACCESS = 1 << 3, B_DPMS = 1 << 4, B_IO_FB_NA = 1 << 5 }; As far as I know these flags are status info flags _from_ the driver. You cannot actively choose items from this list. BeOS R5 and up have a new flag here: B_SUPPORTS_OVERLAYS = 1 << 31 Currently (upto and including V0.13beta2) the matrox driver added flags: (see driverinterface.h) /*dualhead extensions to flags*/ These you can actively choose as a command to the driver: #define DUALHEAD_OFF (0<<6) #define DUALHEAD_CLONE (1<<6) #define DUALHEAD_ON (2<<6) #define DUALHEAD_SWITCH (3<<6) This one is for making things easier: #define DUALHEAD_BITS (3<<6) And here we have a status flag: #define DUALHEAD_CAPABLE (1<<8) Making things easier: #define TV_BITS (3<<9) Commands again: #define TV_MON (0<<9) #define TV_PAL (1<<9) #define TV_NTSC (2<<9) (note: setting (3<<9) will enable TV_NTSC) And the status flag: #define TV_CAPABLE (1<<11) Note: The driver's behaviour will be updated to accept TVout modes while the card is no dualhead card for G100 and G200 if such a card supports TVout. Currently TVout is only supported on the secondary head of G400-G550 dualhead cards. Because the driver will support a video consumer node on the secondary head, and also DVD_MAX support (which is also on the secondary head in TVout mode) the setmode command needs to be able to be given to both heads independantly. Also we need to have to possibility to isolate the secondary head modesetup from the choosen workspace.  In order to support this, the driver's accelerant needs a second settings file, like the app_server settings file to have it's own store of all selected modes, including the FBC (frame buffer config) struct for each mode. This file will need to contain all workspaces modes for the primary head and also (seperate) for the secondary head. Also this file will have flags to select fixed secondary head modeselect (needed for a video consumer node) and flexible secondary head modeselect (needed for DVD_MAX support). The setmode command itself needs to come in a direct mode version (such as it is now), and in a indirect version (which tells the driver to lookup it's actual mode for the selected workspace in the new settings file, and update it with the mode given with this command also). New flags needed to accomodate this are: (Note that this might change, part of it is only needed because of current BeOS compatibility issues. It will at least give me the options I need for now..) We need to tell the driver which workspace is selected for it to fetch the correct modes for the head that isn't adressed by this command (secondary head only if it's not set to FIXED or DVDMAX mode): #define WORKSPACE_BITS (0x1f << 12) Mode type tells the driver how the given mode should be applied: #define MODE_TYPE_BITS (0x07 << 17) As used by DualheadSetup upto and including V0.03a: #define COUPLED_HEAD_MODE (0x00 << 17) For more flexible use (not really needed yet because of BeOS constaints I expect): #define PRIMARY_HEAD_MODE (0x01 << 17) Because of the current BeOS constraints, only the pixelclock (so refreshrate) will be applied, the mode itself will be copied from the primary head mode that's selected for this workspace: #define SECONDARY_HEAD_MODE (0x03 << 17) If the secondary head needs to be decoupled from the workspaces for video consumer node use: #define SET_FIXED_SECONDARY_MODE (0x04 << 17) Same here, but for DVDMAX (so flexible autoset mode) use: #define SET_DVDMAX_SECONDARY_MODE (0x05 << 17) This is the only command that will reset the secondary head to normal (dualhead) use as used upto now: #define CLR_FIXED_DVDMAX_SECONDARY_MODE (0x06 << 17) And status bits to identify the special secondary head modes (all other new bits don't apply on getmode): #define SECONDARY_MODE_STATUS_BITS (0x03 << 20) #define FIXED_SECONDARY_MODE_ACTIVE (0x01 << 20) #define DVDMAX_SECONDARY_MODE_ACTIVE (0x03 << 20) 'Old style' dualhead setup: So if you want to use dualhead as before, you make sure the DVDMAX mode is cleared (if it was set). Now you use one setmode command if you want the same refresh on both heads. If you determine FIXED mode active, a node is in use and you should abort. Single/dualhead mode is determined by the extension bits already included before (DUALHEAD_BITS). 'New style' dualhead setup: If you want to modify the refreshrate of the secondary head, issue another setmode command with SECONDARY_HEAD_MODE set. The mode you send will be evaluated to filter out the refreshrate: that's the one thing that will be used. The rest of the mode will be indentical to the primary head mode for that workspace.  'Video consumer node' setup: The video consumer node can issue a setmode command with the SECONDARY_HEAD_MODE flag set. It issues SET_FIXED_SECONDARY_MODE which will relay the mode to be the new active mode (the flag was already set on activating the node to disable normal dualhead use). Of course the mode to set may be anything you desire (within the cards constraints) here. DVD_MAX mode setup: This mode cannot be combined with FIXED_SECONDARY_MODE. the FIXED mode if set should take precedence because a node is activated in the MediaPrefs panel. So if you determine FIXED mode set, abort. If you proceed, DVD_MAX mode will be selected, disabling the normal dualhead use as soon as the cards overlay units gets occupied with one of two videoformats: 720x480 overlay input pictures in B_YCbCr422 format will set NTSC DVD mode on the secondary head; 720x576 overlay input pictures in B_YCbCr422 format will set PAL DVD mode on the secondary head. The DVD mode will overwrite the normal dualhead mode previously engaged (if so). On freeing the overlay unit, the old mode will be restored. Note that during overlay, you can switch workspaces without loosing the DVD_MAX mode on the secondary head. As soon as overlay ends, the dualhead mode previously engaged for the current selected workspace will be restored. mode settings file issues: The Accelerant will try to open this file at system startup. The contents will be copied to the shared info struct in the accelerant for actual use. If opening the file fails, single head mode in 640x480x8 @ 60Hz will be assumed on all primary heads, the secondary head will be disabled. A new file will be attempted to write to disk. On a setmode command, the driver will update the respective mode store in the shared info struct so it will use the new mode from now on on workspace switching. Also an attempt is made to update the file to disk. final notes: All dualhead options only apply for G400-G550 cards. Older cards do not support dualhead modes (except for the G200 MMS QUAD output card: but this card is only partial supported). Owners of G100 and G200 cards with TVout (both do exist: at least the board layout for these cards seem to have the option for it..) can use TVout in theory (if it's created with a MAVEN chip). The driver only needs marginal updating to support this. By setting DVD or VCD modes on the primary head one could watch movies in these formats on TV in the same quality as G400-G550 owners... Settings DVD and VCD modes directly on the primary head is already working: the mode slopspace (added in driver version 0.14) adds support for the DVD modes this way.  The setmode.timing.mode flags: BeOS supports the following flags here: enum { /* timing flags */ B_BLANK_PEDESTAL = 1 << 27, B_TIMING_INTERLACED = 1 << 28, B_POSITIVE_HSYNC = 1 << 29, B_POSITIVE_VSYNC = 1 << 30, B_SYNC_ON_GREEN = 1 << 31 }; These flags are meant as command flags. Currently the Matrox driver only processes the SYNC flags. The other flags are not processed. In the driver INTERLACED mode is only used internally on G450/G550 TVout. BLANK_PEDESTAL is turned off, and SYNC_ON_GREEN can be set via the mga.settings file with driverversion V0.14 and up. While SYNC_ON_GREEN could be processed on modeswitching this makes no sense to do, because switching a mode will not switch your monitor from being a SYNC_ON_GREEN type of device to a 'normal' type of device. (If someone disagrees, don't hesitate to let me know: I am open to suggestions if valid reasons exist.) 2D/3D acceleration engine and modes/TVout. acceleration engine As long as old style dualsetup is used, or new style setup with only the refreshrates custom to each head, the actual workspace (with the current versions of BeOS) is just one big place divided over two screens max. This means that it behaves as one workspace, one framebuffer. This simpifies driver setup a lot, because the 2D engine can work on both heads without any extra precautions you have to take. As soon as we actually split the big framebuffer into two, independent buffers, this nolonger applies. Now the (single) acceleration engine needs to be told on which framebuffer it will be used. If it is to be used on both buffers, it needs to be told which one is up for the current action. The driver inits the engine only once currently: at the ending stage of the setmode command. In order to use the engine on both spaces, we need to do it as soon as it has to change to another buffer. While this will slow up 2D speed somewhat, it will also improve normal 2D actions on the secondary head a lot of course: as opposed to the engine being fixed to the primary buffer only. Because really seperate outputs on both heads will not be used on BeOS for workspace use, we don't need to worry about it here for now. Since the really seperate output will only be used for video playback currently, also for that use there is no big problem yet. DVDmax uses another feature in the card that can do hardware YUV to RGB colorspace conversion for TVout seperately, and also buffer flipping for this function is done with some hardware that exists seperately for both heads.  Other resolution video needs to be scaled for fullscreen playback though. This could theoretically be done by the acceleration engine, but if it's fixed to the primary head this needs to be done by software for now. This is how it will be at the beginning: first seperate modesetup for both heads so we can have DVDmax and a videonode with software scaling, then later on try if it's possible to let the acceleration engine help out here. TVout chips The G100-G400 TVout chip differs from the chip used on G450 and G550. The older chips are seperately mounted on the videocard, and they can do hardware scaling so the 'desktop' modes can be scaled back to fit on the TV standard's fixed modes. The chips used nowadays, are incorporated on the MGA die, and they are more 'bare bone' than the older ones. These chips can nolonger do the hardware scaling the older chips could do: this is an important difference for people wanting to display their normal Desktop on TVout. While on older chips this can be done easily (640x480 upto 1024x768), the newer chips can only display the native resolution belonging to the choosen TV standard. You might already see what this means: another fine job for the acceleration engine! The problem is, of course, that this will cost bandwitdh for 2D acc on the primary head, as the engine needs to do a scale and filter job every single TVsignal retrace! At least, if you want the 'perfect' TVout solution. It has been said that on Windows you can see the performance drop if you let the engine work hard on main head 2D acceleration: the TVout screen updates drops to about 4 times per second... This is totally unacceptable if you want to play a game on TV, or watch some video: you will actually watch some kind of a (distorted) slide show... On the other hand, once you let the acc engine do the downscaling, you can easily add TVout support for more resolutions: like 1600x1200. Not that you will be able to distinguish the finer details anymore.. So you see it's only natural to first setup the DVD and VCD modes on G450 and G550, and try Desktop representation at a later stage. (While on older cards it's just the other way around by the way.) If it turns out to be possible for me to get Desktop modes to display on TV 'normally', I won't bother to add support for resolutions above 1024x768 BTW. This does not make any sense to do and will only spill more valuable acceleration engine and memory bandwidth. One thing that will be interesting about this is if it will be possible to actually sync correctly to retrace. I expect trouble here, because it might well be that the engine is already occupied at that time by any other 2D acceleration job... Faking hardware overlay It's possible to also simulate a 'backend scaler' in theory with the 2D engine. While this could work relatively simple for double buffered overlay, it's a bit trickier for single buffered overlay. On double buffered overlay the application playing back video is responsible for buffer swapping (which will trigger the acc engine then also), while on single buffered overlay this is not the case: For single buffered overlay the acc engine needs to be triggered by the driver for every retrace, with the same theoretical problem as mentioned in the TVout chips 'chapter'. Such a version of hardware overlay would enable for instance Millenium1, 2 and G100 users some of the benefits of overlay, being hardware scaling and filtering. If it's possible without too many distortions in the general behaviour of the driver that is. On Millenium1 for instance only upscaling would be supported, downscaling cannot be done. Problems that will arise though on doing such a kind of 'overlay' will be disappearing items and menus in front of the videooutput, and the fact that if you switch workspaces, the video will keep following you around. 'Forward looking statement': While I am certainly trying my best, I cannot quarantee that I will be able to incorporate everything I plan. I am just taking one step at the time and I'll just see what features I can get to you... Also please keep in mind that definitions given here might change in the future if my perception of how BeOS behaves changes. The order of things is should be about as follows I think: - split-up modesetup for both heads so seperate output is possible on both heads. This also means adding the modesettings file mentioned earlier, and the extra flags needed. This will add support for fixed seperate secondary head output. - see if DVDmax support can be added. This means first enabling hardware YUV to RGB conversion on the TVout chip, and then trying to get decent retrace synchronisation going: a bit tricky, because it must be done on both heads simultaneously (while they are running seperately from each other, at different refreshrates). - see if acceleration engine scaling and filtering can be setup (2D texture mapping). (- not implementing fake overlay after all I think because of the drawbacks) - see if this engine scaling can be used to display desktops on TV for G450/G550. (- not implementing seperate secondary head 2D acceleration because we cannot use it yet anyway) Two other things have to be done also sometime in between: - see if G100-G400 TVout can be nicely scaled, centered and set with correct refreshrate. - see if G100-400 can be setup in DVD/VCD modes Of course, other driver enhancement work should proceed also: - Millenium1/2 support needs to be completed -DVI support should be added. And: last but not least: -We need a new version of DualheadSetup implementing the stuff mentioned above; -We could use a video consumer node for the driver. (Now _that_ would be nifty ;-) At this point I also want to emphasize that having to test for all those 'uncertain' functions costs a lot of time. This is why from the user's view probably only small differences between driverversions are noted while really a lot of work has to be done 'beneath the surface'... Rudolf. (end of document)txt-sct+??sct-wp--REFTRefTPORT FRAMBBCD"DEADPCFraMFRAMBBCD"PENzPDFraMFRAMBBCD"PENz [DFraMFRAMBBCD"PENzn [DFraMFRAMBBCD" DFraMFRAMBBCD"'>D"FraMFRAMBBCD" 45 HDFraMPorTParTPARTGRFXGRAP>qIt$It$lyr+Layer 1lyr-vew+View 1vew-GraPREFTRefTPORTFRAMBBCD"NɰCD"FraMFRAMBBCD"PENzD"CDFraMFRAMBBCD"PENzDCDFraMFRAMBBCD"PENzDCE"FraMFRAMBBCD"PENzE"CEJFraMFRAMBBCD"PENzEJCEsFraMFRAMBBCD"CEsCEFraMPorTParTPARTPROTREFTRefTPORTFRAMDC@EfFraMPorTParTPARTPAGEREFTRefTPORTFRAMDDFFraMFRAMDKDDFFraMFRAMDDDFFraMFRAME@DDF`FraMFRAMEKDDFFraMFRAME}DDFFraMFRAME@DDFBFraMPorTParTPARTWORDwp++par+ par-txt+ txt-sct+??sct-wp--REFTRefTParTPARTWORDwp++par+ par-txt+thetxt-sct+??sct-wp--REFTRefTParTPARTWORDwp++par+ par-txt+some txt-sct+??sct-wp--REFTRefTParTPARTWORD wp++par+ par-txt+ txt-sct+??sct-wp--REFTRefTParTPARTWORD wp++par+ par-txt+are goodtxt-sct+??sct-wp--REFTRefTParTPARTWORD wp++par+ par-txt+1txt-sct+??sct-wp--REFTRefTParTPARTWORDwp++par+ par-txt+5txt-sct+??sct-wp--REFTRefTParTPARTWORDwp++par+ par-txt+txt-sct+??sct-wp--REFTRefTParTParMCMDMTCMD0WORDWP01!'TCMD0WORDWP01 TCMD4WORDWP06REFURefUTCMD0WORDWP01!'TCMD0WORDWP01!+ TCMD4WORDWP06REFURefUTCMD0WORDWP01!<TCMD4WORDWP06REFURefUTCMD4WORDWP06REFURefUTCMD0WORDWP01 !9TCMD4WORDWP06 REFURefUTCMD0WORDWP01 ATCMD4WORDWP06  REFURefUTCMD0WORDWP01 FTCMD4WORDWP06 REFURefUTCMD0WORDWP03TCMD0WORDWP03mTCMD0WORDWP03'TCMD4WORDWP06 REFURefUTCMD0WORDWP016CmdM ?@ADJ@D>   WOR VersionMgrbPartFactory Table~ Document MiscSetMgrPenMgr StyleMgrSheetMgr SelectionMgrULinksMgr+PartMgr8 CommandMgr HistoryMgr WindowMgrEND!