22  *  hardware to that state. This allows a very clean separation of the fbdev
75  * This structure defines the hardware state of the graphics card. Normally
99      * 	Modern graphical hardware not only supports pipelines but some
104      *  hardware state thus only one exist per card. In this case the
109      *  aware of the entire hardware state that affects it because they share
117      *  states. I hope this covers every possible hardware design. If not
130      * Each one represents the state of the hardware. Most hardware have
131      * just one hardware state. These here represent the default state(s).
144  *	is used is to change from a text mode hardware state to a graphics
178  *	Checks to see if the hardware supports the state requested by
179  *	var passed in. This function does not alter the hardware state!!!
185  *	off by what the hardware can support then we alter the var PASSED in
189  *      next value that is supported by the hardware.  If the value is
190  *      greater than the highest value supported by the hardware, then this
194  *      the hardware is already set at boot up, and cannot be changed.  In
216  *      xxxfb_set_par - Optional function. Alters the hardware state.
223  *	data in var inside fb_info to be supported by the hardware.
225  *      This function is also used to recover/restore the hardware to a
233  *      However, even if your hardware does not support mode changing,
234  *      a set_par might be needed to at least initialize the hardware to
236  *      process that also modifies the same hardware, such as X.
249  *              init your hardware here
271  *  	magnitude which needs to be scaled in this function for the hardware.
290      * Program hardware... do anything you want with transp  in xxxfb_setcolreg()
359      * is acceptable by the hardware.  in xxxfb_setcolreg()
368      * This is the point where the function feeds the color to the hardware  in xxxfb_setcolreg()
370      * the hardware. Note, only FB_VISUAL_DIRECTCOLOR and  in xxxfb_setcolreg()
371      * FB_VISUAL_PSEUDOCOLOR visuals need to write to the hardware palette.  in xxxfb_setcolreg()
372      * If you have code that writes to the hardware CLUT, and it's not  in xxxfb_setcolreg()
428      * If your hardware does not support panning, _do_ _not_ implement this  in xxxfb_pan_display()
451  *      Implements VESA suspend and powerdown modes on hardware that supports
472  * We provide our own functions if we have hardware acceleration
473  * or non packed pixel format layouts. If we have no hardware
481  *		 	 non acclerated hardware and packed pixel based.
508  *                       non acclerated hardware and packed pixel based.
533  *                        non acclerated hardware and packed pixel based.
560  * padded to the next byte.  Most hardware accelerators may require padding to  in xxxfb_imageblit()
568  *	xxxfb_cursor - 	OPTIONAL. If your hardware lacks support
624  *      If the driver has implemented its own hardware-based drawing function,
705      * If your hardware can support any of the hardware accelerated functions  in xxxfb_probe()
708      * FBINFO_HWACCEL_COPYAREA - hardware moves  in xxxfb_probe()
709      * FBINFO_HWACCEL_FILLRECT - hardware fills  in xxxfb_probe()
710      * FBINFO_HWACCEL_IMAGEBLIT - hardware mono->color expansion  in xxxfb_probe()
711      * FBINFO_HWACCEL_YPAN - hardware can pan display in y-axis  in xxxfb_probe()
712      * FBINFO_HWACCEL_YWRAP - hardware can wrap display in y-axis  in xxxfb_probe()
713      * FBINFO_HWACCEL_DISABLED - supports hardware accels, but disabled  in xxxfb_probe()
715      * FBINFO_MISC_TILEBLITTING - hardware can do tile blits  in xxxfb_probe()
791      * The following is done in the case of having hardware with a static  in xxxfb_probe()
803      * will depend on you and the hardware.  If you are sure that your driver  in xxxfb_probe()
806      * Hardware in x86 systems has a VGA core.  Calling set_par() at this  in xxxfb_probe()