22  *  hardware to that state. This allows a very clean separation of the fbdev
74  * This structure defines the hardware state of the graphics card. Normally
98      * 	Modern graphical hardware not only supports pipelines but some 
103      *  hardware state thus only one exist per card. In this case the 
108      *  aware of the entire hardware state that affects it because they share
116      *  states. I hope this covers every possible hardware design. If not
129      * Each one represents the state of the hardware. Most hardware have
130      * just one hardware state. These here represent the default state(s). 
145  *	is used is to change from a text mode hardware state to a graphics
179  *	Checks to see if the hardware supports the state requested by
180  *	var passed in. This function does not alter the hardware state!!! 
186  *	off by what the hardware can support then we alter the var PASSED in
190  *      next value that is supported by the hardware.  If the value is
191  *      greater than the highest value supported by the hardware, then this
195  *      the hardware is already set at boot up, and cannot be changed.  In
217  *      xxxfb_set_par - Optional function. Alters the hardware state.
224  *	data in var inside fb_info to be supported by the hardware. 
226  *      This function is also used to recover/restore the hardware to a
234  *      However, even if your hardware does not support mode changing,
235  *      a set_par might be needed to at least initialize the hardware to
237  *      process that also modifies the same hardware, such as X.
250  *              init your hardware here
272  *  	magnitude which needs to be scaled in this function for the hardware. 
291      * Program hardware... do anything you want with transp  in xxxfb_setcolreg()
360      * is acceptable by the hardware.  in xxxfb_setcolreg()
369      * This is the point where the function feeds the color to the hardware  in xxxfb_setcolreg()
371      * the hardware. Note, only FB_VISUAL_DIRECTCOLOR and  in xxxfb_setcolreg()
372      * FB_VISUAL_PSEUDOCOLOR visuals need to write to the hardware palette.  in xxxfb_setcolreg()
373      * If you have code that writes to the hardware CLUT, and it's not  in xxxfb_setcolreg()
429      * If your hardware does not support panning, _do_ _not_ implement this  in xxxfb_pan_display()
452  *      Implements VESA suspend and powerdown modes on hardware that supports
473  * We provide our own functions if we have hardware acceleration
474  * or non packed pixel format layouts. If we have no hardware 
482  *		 	 non acclerated hardware and packed pixel based.
509  *                       non acclerated hardware and packed pixel based.
534  *                        non acclerated hardware and packed pixel based.
561  * padded to the next byte.  Most hardware accelerators may require padding to  in xxxfb_imageblit()
569  *	xxxfb_cursor - 	OPTIONAL. If your hardware lacks support
625  *      If the driver has implemented its own hardware-based drawing function,
699      * If your hardware can support any of the hardware accelerated functions  in xxxfb_probe()
702      * FBINFO_HWACCEL_COPYAREA - hardware moves  in xxxfb_probe()
703      * FBINFO_HWACCEL_FILLRECT - hardware fills  in xxxfb_probe()
704      * FBINFO_HWACCEL_IMAGEBLIT - hardware mono->color expansion  in xxxfb_probe()
705      * FBINFO_HWACCEL_YPAN - hardware can pan display in y-axis  in xxxfb_probe()
706      * FBINFO_HWACCEL_YWRAP - hardware can wrap display in y-axis  in xxxfb_probe()
707      * FBINFO_HWACCEL_DISABLED - supports hardware accels, but disabled  in xxxfb_probe()
709      * FBINFO_MISC_TILEBLITTING - hardware can do tile blits  in xxxfb_probe()
785      * The following is done in the case of having hardware with a static   in xxxfb_probe()
797      * will depend on you and the hardware.  If you are sure that your driver  in xxxfb_probe()
800      * Hardware in x86 systems has a VGA core.  Calling set_par() at this  in xxxfb_probe()