| 1 | |
| 2 | * linux/drivers/video/skeletonfb.c -- Skeleton for a frame buffer device
|
| 3 | *
|
| 4 | * Modified to new api Jan 2001 by James Simmons ([email protected])
|
| 5 | *
|
| 6 | * Created 28 Dec 1997 by Geert Uytterhoeven
|
| 7 | *
|
| 8 | *
|
| 9 | * I have started rewriting this driver as a example of the upcoming new API
|
| 10 | * The primary goal is to remove the console code from fbdev and place it
|
| 11 | * into fbcon.c. This reduces the code and makes writing a new fbdev driver
|
| 12 | * easy since the author doesn't need to worry about console internals. It
|
| 13 | * also allows the ability to run fbdev without a console/tty system on top
|
| 14 | * of it.
|
| 15 | *
|
| 16 | * First the roles of struct fb_info and struct display have changed. Struct
|
| 17 | * display will go away. The way the new framebuffer console code will
|
| 18 | * work is that it will act to translate data about the tty/console in
|
| 19 | * struct vc_data to data in a device independent way in struct fb_info. Then
|
| 20 | * various functions in struct fb_ops will be called to store the device
|
| 21 | * dependent state in the par field in struct fb_info and to change the
|
| 22 | * hardware to that state. This allows a very clean separation of the fbdev
|
| 23 | * layer from the console layer. It also allows one to use fbdev on its own
|
| 24 | * which is a bounus for embedded devices. The reason this approach works is
|
| 25 | * for each framebuffer device when used as a tty/console device is allocated
|
| 26 | * a set of virtual terminals to it. Only one virtual terminal can be active
|
| 27 | * per framebuffer device. We already have all the data we need in struct
|
| 28 | * vc_data so why store a bunch of colormaps and other fbdev specific data
|
| 29 | * per virtual terminal.
|
| 30 | *
|
| 31 | * As you can see doing this makes the con parameter pretty much useless
|
| 32 | * for struct fb_ops functions, as it should be. Also having struct
|
| 33 | * fb_var_screeninfo and other data in fb_info pretty much eliminates the
|
| 34 | * need for get_fix and get_var. Once all drivers use the fix, var, and cmap
|
| 35 | * fbcon can be written around these fields. This will also eliminate the
|
| 36 | * need to regenerate struct fb_var_screeninfo, struct fb_fix_screeninfo
|
| 37 | * struct fb_cmap every time get_var, get_fix, get_cmap functions are called
|
| 38 | * as many drivers do now.
|
| 39 | *
|
| 40 | * This file is subject to the terms and conditions of the GNU General Public
|
| 41 | * License. See the file COPYING in the main directory of this archive for
|
| 42 | * more details.
|
| 43 |
|
| 44 |
|
| 45 | #include <linux/aperture.h>
|
| 46 | #include <linux/module.h>
|
| 47 | #include <linux/kernel.h>
|
| 48 | #include <linux/errno.h>
|
| 49 | #include <linux/string.h>
|
| 50 | #include <linux/mm.h>
|
| 51 | #include <linux/slab.h>
|
| 52 | #include <linux/delay.h>
|
| 53 | #include <linux/fb.h>
|
| 54 | #include <linux/init.h>
|
| 55 | #include <linux/pci.h>
|
| 56 |
|
| 57 | |
| 58 | * This is just simple sample code.
|
| 59 | *
|
| 60 | * No warranty that it actually compiles.
|
| 61 | * Even less warranty that it actually works :-)
|
| 62 |
|
| 63 |
|
| 64 | |
| 65 | * Driver data
|
| 66 |
|
| 67 | static char *mode_option;
|
| 68 |
|
| 69 | |
| 70 | * If your driver supports multiple boards, you should make the
|
| 71 | * below data types arrays, or allocate them dynamically (using kmalloc()).
|
| 72 |
|
| 73 |
|
| 74 | |
| 75 | * This structure defines the hardware state of the graphics card. Normally
|
| 76 | * you place this in a header file in linux/include/video. This file usually
|
| 77 | * also includes register information. That allows other driver subsystems
|
| 78 | * and userland applications the ability to use the same header file to
|
| 79 | * avoid duplicate work and easy porting of software.
|
| 80 |
|
| 81 | struct xxx_par;
|
| 82 |
|
| 83 | |
| 84 | * Here we define the default structs fb_fix_screeninfo and fb_var_screeninfo
|
| 85 | * if we don't use modedb. If we do use modedb see xxxfb_init how to use it
|
| 86 | * to get a fb_var_screeninfo. Otherwise define a default var as well.
|
| 87 |
|
| 88 | static const struct fb_fix_screeninfo xxxfb_fix = {
|
| 89 | .id = "FB's name",
|
| 90 | .type = FB_TYPE_PACKED_PIXELS,
|
| 91 | .visual = FB_VISUAL_PSEUDOCOLOR,
|
| 92 | .xpanstep = 1,
|
| 93 | .ypanstep = 1,
|
| 94 | .ywrapstep = 1,
|
| 95 | .accel = FB_ACCEL_NONE,
|
| 96 | };
|
| 97 |
|
| 98 | |
| 99 | * Modern graphical hardware not only supports pipelines but some
|
| 100 | * also support multiple monitors where each display can have
|
| 101 | * its own unique data. In this case each display could be
|
| 102 | * represented by a separate framebuffer device thus a separate
|
| 103 | * struct fb_info. Now the struct xxx_par represents the graphics
|
| 104 | * hardware state thus only one exist per card. In this case the
|
| 105 | * struct xxx_par for each graphics card would be shared between
|
| 106 | * every struct fb_info that represents a framebuffer on that card.
|
| 107 | * This allows when one display changes it video resolution (info->var)
|
| 108 | * the other displays know instantly. Each display can always be
|
| 109 | * aware of the entire hardware state that affects it because they share
|
| 110 | * the same xxx_par struct. The other side of the coin is multiple
|
| 111 | * graphics cards that pass data around until it is finally displayed
|
| 112 | * on one monitor. Such examples are the voodoo 1 cards and high end
|
| 113 | * NUMA graphics servers. For this case we have a bunch of pars, each
|
| 114 | * one that represents a graphics state, that belong to one struct
|
| 115 | * fb_info. Their you would want to have *par point to a array of device
|
| 116 | * states and have each struct fb_ops function deal with all those
|
| 117 | * states. I hope this covers every possible hardware design. If not
|
| 118 | * feel free to send your ideas at [email protected]
|
| 119 |
|
| 120 |
|
| 121 | |
| 122 | * If your driver supports multiple boards or it supports multiple
|
| 123 | * framebuffers, you should make these arrays, or allocate them
|
| 124 | * dynamically using framebuffer_alloc() and free them with
|
| 125 | * framebuffer_release().
|
| 126 |
|
| 127 | static struct fb_info info;
|
| 128 |
|
| 129 | |
| 130 | * Each one represents the state of the hardware. Most hardware have
|
| 131 | * just one hardware state. These here represent the default state(s).
|
| 132 |
|
| 133 | static struct xxx_par __initdata current_par;
|
| 134 |
|
| 135 | |
| 136 | * xxxfb_open - Optional function. Called when the framebuffer is
|
| 137 | * first accessed.
|
| 138 | * @info: frame buffer structure that represents a single frame buffer
|
| 139 | * @user: tell us if the userland (value=1) or the console is accessing
|
| 140 | * the framebuffer.
|
| 141 | *
|
| 142 | * This function is the first function called in the framebuffer api.
|
| 143 | * Usually you don't need to provide this function. The case where it
|
| 144 | * is used is to change from a text mode hardware state to a graphics
|
| 145 | * mode state.
|
| 146 | *
|
| 147 | * Returns negative errno on error, or zero on success.
|
| 148 |
|
| 149 | static int xxxfb_open(struct fb_info *info, int user)
|
| 150 | {
|
| 151 | return 0;
|
| 152 | }
|
| 153 |
|
| 154 | |
| 155 | * xxxfb_release - Optional function. Called when the framebuffer
|
| 156 | * device is closed.
|
| 157 | * @info: frame buffer structure that represents a single frame buffer
|
| 158 | * @user: tell us if the userland (value=1) or the console is accessing
|
| 159 | * the framebuffer.
|
| 160 | *
|
| 161 | * Thus function is called when we close /dev/fb or the framebuffer
|
| 162 | * console system is released. Usually you don't need this function.
|
| 163 | * The case where it is usually used is to go from a graphics state
|
| 164 | * to a text mode state.
|
| 165 | *
|
| 166 | * Returns negative errno on error, or zero on success.
|
| 167 |
|
| 168 | static int xxxfb_release(struct fb_info *info, int user)
|
| 169 | {
|
| 170 | return 0;
|
| 171 | }
|
| 172 |
|
| 173 | |
| 174 | * xxxfb_check_var - Optional function. Validates a var passed in.
|
| 175 | * @var: frame buffer variable screen structure
|
| 176 | * @info: frame buffer structure that represents a single frame buffer
|
| 177 | *
|
| 178 | * Checks to see if the hardware supports the state requested by
|
| 179 | * var passed in. This function does not alter the hardware state!!!
|
| 180 | * This means the data stored in struct fb_info and struct xxx_par do
|
| 181 | * not change. This includes the var inside of struct fb_info.
|
| 182 | * Do NOT change these. This function can be called on its own if we
|
| 183 | * intent to only test a mode and not actually set it. The stuff in
|
| 184 | * modedb.c is a example of this. If the var passed in is slightly
|
| 185 | * off by what the hardware can support then we alter the var PASSED in
|
| 186 | * to what we can do.
|
| 187 | *
|
| 188 | * For values that are off, this function must round them _up_ to the
|
| 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
|
| 191 | * function must return -EINVAL.
|
| 192 | *
|
| 193 | * Exception to the above rule: Some drivers have a fixed mode, ie,
|
| 194 | * the hardware is already set at boot up, and cannot be changed. In
|
| 195 | * this case, it is more acceptable that this function just return
|
| 196 | * a copy of the currently working var (info->var). Better is to not
|
| 197 | * implement this function, as the upper layer will do the copying
|
| 198 | * of the current var for you.
|
| 199 | *
|
| 200 | * Note: This is the only function where the contents of var can be
|
| 201 | * freely adjusted after the driver has been registered. If you find
|
| 202 | * that you have code outside of this function that alters the content
|
| 203 | * of var, then you are doing something wrong. Note also that the
|
| 204 | * contents of info->var must be left untouched at all times after
|
| 205 | * driver registration.
|
| 206 | *
|
| 207 | * Returns negative errno on error, or zero on success.
|
| 208 |
|
| 209 | static int xxxfb_check_var(struct fb_var_screeninfo *var, struct fb_info *info)
|
| 210 | {
|
| 211 |
|
| 212 | return 0;
|
| 213 | }
|
| 214 |
|
| 215 | |
| 216 | * xxxfb_set_par - Optional function. Alters the hardware state.
|
| 217 | * @info: frame buffer structure that represents a single frame buffer
|
| 218 | *
|
| 219 | * Using the fb_var_screeninfo in fb_info we set the resolution of the
|
| 220 | * this particular framebuffer. This function alters the par AND the
|
| 221 | * fb_fix_screeninfo stored in fb_info. It doesn't not alter var in
|
| 222 | * fb_info since we are using that data. This means we depend on the
|
| 223 | * data in var inside fb_info to be supported by the hardware.
|
| 224 | *
|
| 225 | * This function is also used to recover/restore the hardware to a
|
| 226 | * known working state.
|
| 227 | *
|
| 228 | * xxxfb_check_var is always called before xxxfb_set_par to ensure that
|
| 229 | * the contents of var is always valid.
|
| 230 | *
|
| 231 | * Again if you can't change the resolution you don't need this function.
|
| 232 | *
|
| 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
|
| 235 | * a known working state, especially if it came back from another
|
| 236 | * process that also modifies the same hardware, such as X.
|
| 237 | *
|
| 238 | * If this is the case, a combination such as the following should work:
|
| 239 | *
|
| 240 | * static int xxxfb_check_var(struct fb_var_screeninfo *var,
|
| 241 | * struct fb_info *info)
|
| 242 | * {
|
| 243 | * *var = info->var;
|
| 244 | * return 0;
|
| 245 | * }
|
| 246 | *
|
| 247 | * static int xxxfb_set_par(struct fb_info *info)
|
| 248 | * {
|
| 249 | * init your hardware here
|
| 250 | * }
|
| 251 | *
|
| 252 | * Returns negative errno on error, or zero on success.
|
| 253 |
|
| 254 | static int xxxfb_set_par(struct fb_info *info)
|
| 255 | {
|
| 256 | struct xxx_par *par = info->par;
|
| 257 |
|
| 258 | return 0;
|
| 259 | }
|
| 260 |
|
| 261 | |
| 262 | * xxxfb_setcolreg - Optional function. Sets a color register.
|
| 263 | * @regno: Which register in the CLUT we are programming
|
| 264 | * @red: The red value which can be up to 16 bits wide
|
| 265 | * @green: The green value which can be up to 16 bits wide
|
| 266 | * @blue: The blue value which can be up to 16 bits wide.
|
| 267 | * @transp: If supported, the alpha value which can be up to 16 bits wide.
|
| 268 | * @info: frame buffer info structure
|
| 269 | *
|
| 270 | * Set a single color register. The values supplied have a 16 bit
|
| 271 | * magnitude which needs to be scaled in this function for the hardware.
|
| 272 | * Things to take into consideration are how many color registers, if
|
| 273 | * any, are supported with the current color visual. With truecolor mode
|
| 274 | * no color palettes are supported. Here a pseudo palette is created
|
| 275 | * which we store the value in pseudo_palette in struct fb_info. For
|
| 276 | * pseudocolor mode we have a limited color palette. To deal with this
|
| 277 | * we can program what color is displayed for a particular pixel value.
|
| 278 | * DirectColor is similar in that we can program each color field. If
|
| 279 | * we have a static colormap we don't need to implement this function.
|
| 280 | *
|
| 281 | * Returns negative errno on error, or zero on success.
|
| 282 |
|
| 283 | static int xxxfb_setcolreg(unsigned regno, unsigned red, unsigned green,
|
| 284 | unsigned blue, unsigned transp,
|
| 285 | struct fb_info *info)
|
| 286 | {
|
| 287 | if (regno >= 256)
|
| 288 | return -EINVAL;
|
| 289 | |
| 290 | * Program hardware... do anything you want with transp
|
| 291 |
|
| 292 |
|
| 293 |
|
| 294 | if (info->var.grayscale) {
|
| 295 |
|
| 296 | red = green = blue = (red * 77 + green * 151 + blue * 28) >> 8;
|
| 297 | }
|
| 298 |
|
| 299 | |
| 300 | * var->{color}.offset contains start of bitfield
|
| 301 | * var->{color}.length contains length of bitfield
|
| 302 | * {hardwarespecific} contains width of DAC
|
| 303 | * pseudo_palette[X] is programmed to (X << red.offset) |
|
| 304 | * (X << green.offset) |
|
| 305 | * (X << blue.offset)
|
| 306 | * RAMDAC[X] is programmed to (red, green, blue)
|
| 307 | * color depth = SUM(var->{color}.length)
|
| 308 | *
|
| 309 | * Pseudocolor:
|
| 310 | * var->{color}.offset is 0 unless the palette index takes less than
|
| 311 | * bits_per_pixel bits and is stored in the upper
|
| 312 | * bits of the pixel value
|
| 313 | * var->{color}.length is set so that 1 << length is the number of
|
| 314 | * available palette entries
|
| 315 | * pseudo_palette is not used
|
| 316 | * RAMDAC[X] is programmed to (red, green, blue)
|
| 317 | * color depth = var->{color}.length
|
| 318 | *
|
| 319 | * Static pseudocolor:
|
| 320 | * same as Pseudocolor, but the RAMDAC is not programmed (read-only)
|
| 321 | *
|
| 322 | * Mono01/Mono10:
|
| 323 | * Has only 2 values, black on white or white on black (fg on bg),
|
| 324 | * var->{color}.offset is 0
|
| 325 | * white = (1 << var->{color}.length) - 1, black = 0
|
| 326 | * pseudo_palette is not used
|
| 327 | * RAMDAC does not exist
|
| 328 | * color depth is always 2
|
| 329 | *
|
| 330 | * Truecolor:
|
| 331 | * does not use RAMDAC (usually has 3 of them).
|
| 332 | * var->{color}.offset contains start of bitfield
|
| 333 | * var->{color}.length contains length of bitfield
|
| 334 | * pseudo_palette is programmed to (red << red.offset) |
|
| 335 | * (green << green.offset) |
|
| 336 | * (blue << blue.offset) |
|
| 337 | * (transp << transp.offset)
|
| 338 | * RAMDAC does not exist
|
| 339 | * color depth = SUM(var->{color}.length})
|
| 340 | *
|
| 341 | * The color depth is used by fbcon for choosing the logo and also
|
| 342 | * for color palette transformation if color depth < 4
|
| 343 | *
|
| 344 | * As can be seen from the above, the field bits_per_pixel is _NOT_
|
| 345 | * a criteria for describing the color visual.
|
| 346 | *
|
| 347 | * A common mistake is assuming that bits_per_pixel <= 8 is pseudocolor,
|
| 348 | * and higher than that, true/directcolor. This is incorrect, one needs
|
| 349 | * to look at the fix->visual.
|
| 350 | *
|
| 351 | * Another common mistake is using bits_per_pixel to calculate the color
|
| 352 | * depth. The bits_per_pixel field does not directly translate to color
|
| 353 | * depth. You have to compute for the color depth (using the color
|
| 354 | * bitfields) and fix->visual as seen above.
|
| 355 |
|
| 356 |
|
| 357 | |
| 358 | * This is the point where the color is converted to something that
|
| 359 | * is acceptable by the hardware.
|
| 360 |
|
| 361 | #define CNVT_TOHW(val,width) ((((val)<<(width))+0x7FFF-(val))>>16)
|
| 362 | red = CNVT_TOHW(red, info->var.red.length);
|
| 363 | green = CNVT_TOHW(green, info->var.green.length);
|
| 364 | blue = CNVT_TOHW(blue, info->var.blue.length);
|
| 365 | transp = CNVT_TOHW(transp, info->var.transp.length);
|
| 366 | #undef CNVT_TOHW
|
| 367 | |
| 368 | * This is the point where the function feeds the color to the hardware
|
| 369 | * palette after converting the colors to something acceptable by
|
| 370 | * the hardware. Note, only FB_VISUAL_DIRECTCOLOR and
|
| 371 | * FB_VISUAL_PSEUDOCOLOR visuals need to write to the hardware palette.
|
| 372 | * If you have code that writes to the hardware CLUT, and it's not
|
| 373 | * any of the above visuals, then you are doing something wrong.
|
| 374 |
|
| 375 | if (info->fix.visual == FB_VISUAL_DIRECTCOLOR ||
|
| 376 | info->fix.visual == FB_VISUAL_TRUECOLOR)
|
| 377 | write_{red|green|blue|transp}_to_clut();
|
| 378 |
|
| 379 | |
| 380 | * info->pseudo_palette. This structure is used _only_ by fbcon, thus
|
| 381 | * it only contains 16 entries to match the number of colors supported
|
| 382 | * by the console. The pseudo_palette is used only if the visual is
|
| 383 | * in directcolor or truecolor mode. With other visuals, the
|
| 384 | * pseudo_palette is not used. (This might change in the future.)
|
| 385 | *
|
| 386 | * The contents of the pseudo_palette is in raw pixel format. Ie, each
|
| 387 | * entry can be written directly to the framebuffer without any conversion.
|
| 388 | * The pseudo_palette is (void *). However, if using the generic
|
| 389 | * drawing functions (cfb_imageblit, cfb_fillrect), the pseudo_palette
|
| 390 | * must be casted to (u32 *) _regardless_ of the bits per pixel. If the
|
| 391 | * driver is using its own drawing functions, then it can use whatever
|
| 392 | * size it wants.
|
| 393 |
|
| 394 | if (info->fix.visual == FB_VISUAL_TRUECOLOR ||
|
| 395 | info->fix.visual == FB_VISUAL_DIRECTCOLOR) {
|
| 396 | u32 v;
|
| 397 |
|
| 398 | if (regno >= 16)
|
| 399 | return -EINVAL;
|
| 400 |
|
| 401 | v = (red << info->var.red.offset) |
|
| 402 | (green << info->var.green.offset) |
|
| 403 | (blue << info->var.blue.offset) |
|
| 404 | (transp << info->var.transp.offset);
|
| 405 |
|
| 406 | ((u32*)(info->pseudo_palette))[regno] = v;
|
| 407 | }
|
| 408 |
|
| 409 |
|
| 410 | return 0;
|
| 411 | }
|
| 412 |
|
| 413 | |
| 414 | * xxxfb_pan_display - NOT a required function. Pans the display.
|
| 415 | * @var: frame buffer variable screen structure
|
| 416 | * @info: frame buffer structure that represents a single frame buffer
|
| 417 | *
|
| 418 | * Pan (or wrap, depending on the `vmode' field) the display using the
|
| 419 | * `xoffset' and `yoffset' fields of the `var' structure.
|
| 420 | * If the values don't fit, return -EINVAL.
|
| 421 | *
|
| 422 | * Returns negative errno on error, or zero on success.
|
| 423 |
|
| 424 | static int xxxfb_pan_display(struct fb_var_screeninfo *var,
|
| 425 | struct fb_info *info)
|
| 426 | {
|
| 427 | |
| 428 | * If your hardware does not support panning, _do_ _not_ implement this
|
| 429 | * function. Creating a dummy function will just confuse user apps.
|
| 430 |
|
| 431 |
|
| 432 | |
| 433 | * Note that even if this function is fully functional, a setting of
|
| 434 | * 0 in both xpanstep and ypanstep means that this function will never
|
| 435 | * get called.
|
| 436 |
|
| 437 |
|
| 438 |
|
| 439 | return 0;
|
| 440 | }
|
| 441 |
|
| 442 | |
| 443 | * xxxfb_blank - NOT a required function. Blanks the display.
|
| 444 | * @blank_mode: the blank mode we want.
|
| 445 | * @info: frame buffer structure that represents a single frame buffer
|
| 446 | *
|
| 447 | * Blank the screen if blank_mode != FB_BLANK_UNBLANK, else unblank.
|
| 448 | * Return 0 if blanking succeeded, != 0 if un-/blanking failed due to
|
| 449 | * e.g. a video mode which doesn't support it.
|
| 450 | *
|
| 451 | * Implements VESA suspend and powerdown modes on hardware that supports
|
| 452 | * disabling hsync/vsync:
|
| 453 | *
|
| 454 | * FB_BLANK_NORMAL = display is blanked, syncs are on.
|
| 455 | * FB_BLANK_HSYNC_SUSPEND = hsync off
|
| 456 | * FB_BLANK_VSYNC_SUSPEND = vsync off
|
| 457 | * FB_BLANK_POWERDOWN = hsync and vsync off
|
| 458 | *
|
| 459 | * If implementing this function, at least support FB_BLANK_UNBLANK.
|
| 460 | * Return !0 for any modes that are unimplemented.
|
| 461 | *
|
| 462 |
|
| 463 | static int xxxfb_blank(int blank_mode, struct fb_info *info)
|
| 464 | {
|
| 465 |
|
| 466 | return 0;
|
| 467 | }
|
| 468 |
|
| 469 |
|
| 470 |
|
| 471 | |
| 472 | * We provide our own functions if we have hardware acceleration
|
| 473 | * or non packed pixel format layouts. If we have no hardware
|
| 474 | * acceleration, we can use a generic unaccelerated function. If using
|
| 475 | * a pack pixel format just use the functions in cfb_*.c. Each file
|
| 476 | * has one of the three different accel functions we support.
|
| 477 |
|
| 478 |
|
| 479 | |
| 480 | * xxxfb_fillrect - REQUIRED function. Can use generic routines if
|
| 481 | * non acclerated hardware and packed pixel based.
|
| 482 | * Draws a rectangle on the screen.
|
| 483 | *
|
| 484 | * @info: frame buffer structure that represents a single frame buffer
|
| 485 | * @region: The structure representing the rectangular region we
|
| 486 | * wish to draw to.
|
| 487 | *
|
| 488 | * This drawing operation places/removes a retangle on the screen
|
| 489 | * depending on the rastering operation with the value of color which
|
| 490 | * is in the current color depth format.
|
| 491 |
|
| 492 | void xxxfb_fillrect(struct fb_info *p, const struct fb_fillrect *region)
|
| 493 | {
|
| 494 | |
| 495 | *
|
| 496 | * @dx: The x and y corrdinates of the upper left hand corner of the
|
| 497 | * @dy: area we want to draw to.
|
| 498 | * @width: How wide the rectangle is we want to draw.
|
| 499 | * @height: How tall the rectangle is we want to draw.
|
| 500 | * @color: The color to fill in the rectangle with.
|
| 501 | * @rop: The raster operation. We can draw the rectangle with a COPY
|
| 502 | * of XOR which provides erasing effect.
|
| 503 |
|
| 504 | }
|
| 505 |
|
| 506 | |
| 507 | * xxxfb_copyarea - REQUIRED function. Can use generic routines if
|
| 508 | * non acclerated hardware and packed pixel based.
|
| 509 | * Copies one area of the screen to another area.
|
| 510 | *
|
| 511 | * @info: frame buffer structure that represents a single frame buffer
|
| 512 | * @area: Structure providing the data to copy the framebuffer contents
|
| 513 | * from one region to another.
|
| 514 | *
|
| 515 | * This drawing operation copies a rectangular area from one area of the
|
| 516 | * screen to another area.
|
| 517 |
|
| 518 | void xxxfb_copyarea(struct fb_info *p, const struct fb_copyarea *area)
|
| 519 | {
|
| 520 | |
| 521 | * @dx: The x and y coordinates of the upper left hand corner of the
|
| 522 | * @dy: destination area on the screen.
|
| 523 | * @width: How wide the rectangle is we want to copy.
|
| 524 | * @height: How tall the rectangle is we want to copy.
|
| 525 | * @sx: The x and y coordinates of the upper left hand corner of the
|
| 526 | * @sy: source area on the screen.
|
| 527 |
|
| 528 | }
|
| 529 |
|
| 530 |
|
| 531 | |
| 532 | * xxxfb_imageblit - REQUIRED function. Can use generic routines if
|
| 533 | * non acclerated hardware and packed pixel based.
|
| 534 | * Copies a image from system memory to the screen.
|
| 535 | *
|
| 536 | * @info: frame buffer structure that represents a single frame buffer
|
| 537 | * @image: structure defining the image.
|
| 538 | *
|
| 539 | * This drawing operation draws a image on the screen. It can be a
|
| 540 | * mono image (needed for font handling) or a color image (needed for
|
| 541 | * tux).
|
| 542 |
|
| 543 | void xxxfb_imageblit(struct fb_info *p, const struct fb_image *image)
|
| 544 | {
|
| 545 | |
| 546 | * @dx: The x and y coordinates of the upper left hand corner of the
|
| 547 | * @dy: destination area to place the image on the screen.
|
| 548 | * @width: How wide the image is we want to copy.
|
| 549 | * @height: How tall the image is we want to copy.
|
| 550 | * @fg_color: For mono bitmap images this is color data for
|
| 551 | * @bg_color: the foreground and background of the image to
|
| 552 | * write directly to the frmaebuffer.
|
| 553 | * @depth: How many bits represent a single pixel for this image.
|
| 554 | * @data: The actual data used to construct the image on the display.
|
| 555 | * @cmap: The colormap used for color images.
|
| 556 |
|
| 557 |
|
| 558 | |
| 559 | * The generic function, cfb_imageblit, expects that the bitmap scanlines are
|
| 560 | * padded to the next byte. Most hardware accelerators may require padding to
|
| 561 | * the next u16 or the next u32. If that is the case, the driver can specify
|
| 562 | * this by setting info->pixmap.scan_align = 2 or 4. See a more
|
| 563 | * comprehensive description of the pixmap below.
|
| 564 |
|
| 565 | }
|
| 566 |
|
| 567 | |
| 568 | * xxxfb_cursor - OPTIONAL. If your hardware lacks support
|
| 569 | * for a cursor, leave this field NULL.
|
| 570 | *
|
| 571 | * @info: frame buffer structure that represents a single frame buffer
|
| 572 | * @cursor: structure defining the cursor to draw.
|
| 573 | *
|
| 574 | * This operation is used to set or alter the properities of the
|
| 575 | * cursor.
|
| 576 | *
|
| 577 | * Returns negative errno on error, or zero on success.
|
| 578 |
|
| 579 | int xxxfb_cursor(struct fb_info *info, struct fb_cursor *cursor)
|
| 580 | {
|
| 581 | |
| 582 | * @set: Which fields we are altering in struct fb_cursor
|
| 583 | * @enable: Disable or enable the cursor
|
| 584 | * @rop: The bit operation we want to do.
|
| 585 | * @mask: This is the cursor mask bitmap.
|
| 586 | * @dest: A image of the area we are going to display the cursor.
|
| 587 | * Used internally by the driver.
|
| 588 | * @hot: The hot spot.
|
| 589 | * @image: The actual data for the cursor image.
|
| 590 | *
|
| 591 | * NOTES ON FLAGS (cursor->set):
|
| 592 | *
|
| 593 | * FB_CUR_SETIMAGE - the cursor image has changed (cursor->image.data)
|
| 594 | * FB_CUR_SETPOS - the cursor position has changed (cursor->image.dx|dy)
|
| 595 | * FB_CUR_SETHOT - the cursor hot spot has changed (cursor->hot.dx|dy)
|
| 596 | * FB_CUR_SETCMAP - the cursor colors has changed (cursor->fg_color|bg_color)
|
| 597 | * FB_CUR_SETSHAPE - the cursor bitmask has changed (cursor->mask)
|
| 598 | * FB_CUR_SETSIZE - the cursor size has changed (cursor->width|height)
|
| 599 | * FB_CUR_SETALL - everything has changed
|
| 600 | *
|
| 601 | * NOTES ON ROPs (cursor->rop, Raster Operation)
|
| 602 | *
|
| 603 | * ROP_XOR - cursor->image.data XOR cursor->mask
|
| 604 | * ROP_COPY - curosr->image.data AND cursor->mask
|
| 605 | *
|
| 606 | * OTHER NOTES:
|
| 607 | *
|
| 608 | * - fbcon only supports a 2-color cursor (cursor->image.depth = 1)
|
| 609 | * - The fb_cursor structure, @cursor, _will_ always contain valid
|
| 610 | * fields, whether any particular bitfields in cursor->set is set
|
| 611 | * or not.
|
| 612 |
|
| 613 | }
|
| 614 |
|
| 615 | |
| 616 | * xxxfb_sync - NOT a required function. Normally the accel engine
|
| 617 | * for a graphics card take a specific amount of time.
|
| 618 | * Often we have to wait for the accelerator to finish
|
| 619 | * its operation before we can write to the framebuffer
|
| 620 | * so we can have consistent display output.
|
| 621 | *
|
| 622 | * @info: frame buffer structure that represents a single frame buffer
|
| 623 | *
|
| 624 | * If the driver has implemented its own hardware-based drawing function,
|
| 625 | * implementing this function is highly recommended.
|
| 626 |
|
| 627 | int xxxfb_sync(struct fb_info *info)
|
| 628 | {
|
| 629 | return 0;
|
| 630 | }
|
| 631 |
|
| 632 | |
| 633 | * Frame buffer operations
|
| 634 |
|
| 635 |
|
| 636 | static const struct fb_ops xxxfb_ops = {
|
| 637 | .owner = THIS_MODULE,
|
| 638 | .fb_open = xxxfb_open,
|
| 639 | .fb_read = xxxfb_read,
|
| 640 | .fb_write = xxxfb_write,
|
| 641 | .fb_release = xxxfb_release,
|
| 642 | .fb_check_var = xxxfb_check_var,
|
| 643 | .fb_set_par = xxxfb_set_par,
|
| 644 | .fb_setcolreg = xxxfb_setcolreg,
|
| 645 | .fb_blank = xxxfb_blank,
|
| 646 | .fb_pan_display = xxxfb_pan_display,
|
| 647 | .fb_fillrect = xxxfb_fillrect,
|
| 648 | .fb_copyarea = xxxfb_copyarea,
|
| 649 | .fb_imageblit = xxxfb_imageblit,
|
| 650 | .fb_cursor = xxxfb_cursor,
|
| 651 | .fb_sync = xxxfb_sync,
|
| 652 | .fb_ioctl = xxxfb_ioctl,
|
| 653 | .fb_mmap = xxxfb_mmap,
|
| 654 | };
|
| 655 |
|
| 656 |
|
| 657 |
|
| 658 | |
| 659 | * Initialization
|
| 660 |
|
| 661 |
|
| 662 |
|
| 663 | static int xxxfb_probe(struct pci_dev *dev, const struct pci_device_id *ent)
|
| 664 | {
|
| 665 | struct fb_info *info;
|
| 666 | struct xxx_par *par;
|
| 667 | struct device *device = &dev->dev;
|
| 668 | int cmap_len, retval;
|
| 669 |
|
| 670 | |
| 671 | * Remove firmware-based drivers that create resource conflicts.
|
| 672 |
|
| 673 | retval = aperture_remove_conflicting_pci_devices(pdev, "xxxfb");
|
| 674 | if (retval)
|
| 675 | return retval;
|
| 676 |
|
| 677 | |
| 678 | * Dynamically allocate info and par
|
| 679 |
|
| 680 | info = framebuffer_alloc(sizeof(struct xxx_par), device);
|
| 681 |
|
| 682 | if (!info) {
|
| 683 |
|
| 684 | }
|
| 685 |
|
| 686 | par = info->par;
|
| 687 |
|
| 688 | |
| 689 | * Here we set the screen_base to the virtual memory address
|
| 690 | * for the framebuffer. Usually we obtain the resource address
|
| 691 | * from the bus layer and then translate it to virtual memory
|
| 692 | * space via ioremap. Consult ioport.h.
|
| 693 |
|
| 694 | info->screen_base = framebuffer_virtual_memory;
|
| 695 | info->fbops = &xxxfb_ops;
|
| 696 | info->fix = xxxfb_fix;
|
| 697 | info->pseudo_palette = pseudo_palette; |
| 698 | * 16-member array
|
| 699 |
|
| 700 | |
| 701 | * Set up flags to indicate what sort of acceleration your
|
| 702 | * driver can provide (pan/wrap/copyarea/etc.) and whether it
|
| 703 | * is a module -- see FBINFO_* in include/linux/fb.h
|
| 704 | *
|
| 705 | * If your hardware can support any of the hardware accelerated functions
|
| 706 | * fbcon performance will improve if info->flags is set properly.
|
| 707 | *
|
| 708 | * FBINFO_HWACCEL_COPYAREA - hardware moves
|
| 709 | * FBINFO_HWACCEL_FILLRECT - hardware fills
|
| 710 | * FBINFO_HWACCEL_IMAGEBLIT - hardware mono->color expansion
|
| 711 | * FBINFO_HWACCEL_YPAN - hardware can pan display in y-axis
|
| 712 | * FBINFO_HWACCEL_YWRAP - hardware can wrap display in y-axis
|
| 713 | * FBINFO_HWACCEL_DISABLED - supports hardware accels, but disabled
|
| 714 | * FBINFO_READS_FAST - if set, prefer moves over mono->color expansion
|
| 715 | * FBINFO_MISC_TILEBLITTING - hardware can do tile blits
|
| 716 | *
|
| 717 | * NOTE: These are for fbcon use only.
|
| 718 |
|
| 719 | info->flags = 0;
|
| 720 |
|
| 721 |
|
| 722 | |
| 723 | * The struct pixmap is a scratch pad for the drawing functions. This
|
| 724 | * is where the monochrome bitmap is constructed by the higher layers
|
| 725 | * and then passed to the accelerator. For drivers that uses
|
| 726 | * cfb_imageblit, you can skip this part. For those that have a more
|
| 727 | * rigorous requirement, this stage is needed
|
| 728 |
|
| 729 |
|
| 730 | |
| 731 | * large enough that memory is wasted. A safe size is
|
| 732 | * (max_xres * max_font_height/8). max_xres is driver dependent,
|
| 733 | * max_font_height is 32.
|
| 734 |
|
| 735 | info->pixmap.addr = kmalloc(PIXMAP_SIZE, GFP_KERNEL);
|
| 736 | if (!info->pixmap.addr) {
|
| 737 |
|
| 738 | }
|
| 739 |
|
| 740 | info->pixmap.size = PIXMAP_SIZE;
|
| 741 |
|
| 742 | |
| 743 | * FB_PIXMAP_SYSTEM - memory is in system ram
|
| 744 | * FB_PIXMAP_IO - memory is iomapped
|
| 745 | * FB_PIXMAP_SYNC - if set, will call fb_sync() per access to pixmap,
|
| 746 | * usually if FB_PIXMAP_IO is set.
|
| 747 | *
|
| 748 | * Currently, FB_PIXMAP_IO is unimplemented.
|
| 749 |
|
| 750 | info->pixmap.flags = FB_PIXMAP_SYSTEM;
|
| 751 |
|
| 752 | |
| 753 | * scan_align is the number of padding for each scanline. It is in bytes.
|
| 754 | * Thus for accelerators that need padding to the next u32, put 4 here.
|
| 755 |
|
| 756 | info->pixmap.scan_align = 4;
|
| 757 |
|
| 758 | |
| 759 | * buf_align is the amount to be padded for the buffer. For example,
|
| 760 | * the i810fb needs a scan_align of 2 but expects it to be fed with
|
| 761 | * dwords, so a buf_align = 4 is required.
|
| 762 |
|
| 763 | info->pixmap.buf_align = 4;
|
| 764 |
|
| 765 | |
| 766 | * ie. some epson cards allow 16-bit access only. Most drivers will
|
| 767 | * be safe with u32 here.
|
| 768 | *
|
| 769 | * NOTE: This field is currently unused.
|
| 770 |
|
| 771 | info->pixmap.access_align = 32;
|
| 772 |
|
| 773 |
|
| 774 | |
| 775 | * This should give a reasonable default video mode. The following is
|
| 776 | * done when we can set a video mode.
|
| 777 |
|
| 778 | if (!mode_option)
|
| 779 | mode_option = "640x480@60";
|
| 780 |
|
| 781 | retval = fb_find_mode(&info->var, info, mode_option, NULL, 0, NULL, 8);
|
| 782 |
|
| 783 | if (!retval || retval == 4)
|
| 784 | return -EINVAL;
|
| 785 |
|
| 786 |
|
| 787 | if (fb_alloc_cmap(&info->cmap, cmap_len, 0))
|
| 788 | return -ENOMEM;
|
| 789 |
|
| 790 | |
| 791 | * The following is done in the case of having hardware with a static
|
| 792 | * mode. If we are setting the mode ourselves we don't call this.
|
| 793 |
|
| 794 | info->var = xxxfb_var;
|
| 795 |
|
| 796 | |
| 797 | * For drivers that can...
|
| 798 |
|
| 799 | xxxfb_check_var(&info->var, info);
|
| 800 |
|
| 801 | |
| 802 | * Does a call to fb_set_par() before register_framebuffer needed? This
|
| 803 | * will depend on you and the hardware. If you are sure that your driver
|
| 804 | * is the only device in the system, a call to fb_set_par() is safe.
|
| 805 | *
|
| 806 | * Hardware in x86 systems has a VGA core. Calling set_par() at this
|
| 807 | * point will corrupt the VGA console, so it might be safer to skip a
|
| 808 | * call to set_par here and just allow fbcon to do it for you.
|
| 809 |
|
| 810 |
|
| 811 |
|
| 812 | if (register_framebuffer(info) < 0) {
|
| 813 | fb_dealloc_cmap(&info->cmap);
|
| 814 | return -EINVAL;
|
| 815 | }
|
| 816 | fb_info(info, "%s frame buffer device\n", info->fix.id);
|
| 817 | pci_set_drvdata(dev, info);
|
| 818 | return 0;
|
| 819 | }
|
| 820 |
|
| 821 | |
| 822 | * Cleanup
|
| 823 |
|
| 824 |
|
| 825 | static void xxxfb_remove(struct pci_dev *dev)
|
| 826 | {
|
| 827 | struct fb_info *info = pci_get_drvdata(dev);
|
| 828 |
|
| 829 |
|
| 830 | if (info) {
|
| 831 | unregister_framebuffer(info);
|
| 832 | fb_dealloc_cmap(&info->cmap);
|
| 833 |
|
| 834 | framebuffer_release(info);
|
| 835 | }
|
| 836 | }
|
| 837 |
|
| 838 | #ifdef CONFIG_PCI
|
| 839 | #ifdef CONFIG_PM
|
| 840 | |
| 841 | * xxxfb_suspend - Optional but recommended function. Suspend the device.
|
| 842 | * @dev: PCI device
|
| 843 | * @msg: the suspend event code.
|
| 844 | *
|
| 845 | * See Documentation/driver-api/pm/devices.rst for more information
|
| 846 |
|
| 847 | static int xxxfb_suspend(struct device *dev)
|
| 848 | {
|
| 849 | struct fb_info *info = dev_get_drvdata(dev);
|
| 850 | struct xxxfb_par *par = info->par;
|
| 851 |
|
| 852 |
|
| 853 | return 0;
|
| 854 | }
|
| 855 |
|
| 856 | |
| 857 | * xxxfb_resume - Optional but recommended function. Resume the device.
|
| 858 | * @dev: PCI device
|
| 859 | *
|
| 860 | * See Documentation/driver-api/pm/devices.rst for more information
|
| 861 |
|
| 862 | static int xxxfb_resume(struct device *dev)
|
| 863 | {
|
| 864 | struct fb_info *info = dev_get_drvdata(dev);
|
| 865 | struct xxxfb_par *par = info->par;
|
| 866 |
|
| 867 |
|
| 868 | return 0;
|
| 869 | }
|
| 870 | #else
|
| 871 | #define xxxfb_suspend NULL
|
| 872 | #define xxxfb_resume NULL
|
| 873 | #endif
|
| 874 |
|
| 875 | static const struct pci_device_id xxxfb_id_table[] = {
|
| 876 | { PCI_VENDOR_ID_XXX, PCI_DEVICE_ID_XXX,
|
| 877 | PCI_ANY_ID, PCI_ANY_ID, PCI_BASE_CLASS_DISPLAY << 16,
|
| 878 | PCI_CLASS_MASK, 0 },
|
| 879 | { 0, }
|
| 880 | };
|
| 881 |
|
| 882 | static SIMPLE_DEV_PM_OPS(xxxfb_pm_ops, xxxfb_suspend, xxxfb_resume);
|
| 883 |
|
| 884 |
|
| 885 | static struct pci_driver xxxfb_driver = {
|
| 886 | .name = "xxxfb",
|
| 887 | .id_table = xxxfb_id_table,
|
| 888 | .probe = xxxfb_probe,
|
| 889 | .remove = xxxfb_remove,
|
| 890 | .driver.pm = xxxfb_pm_ops,
|
| 891 | };
|
| 892 |
|
| 893 | MODULE_DEVICE_TABLE(pci, xxxfb_id_table);
|
| 894 |
|
| 895 | static int __init xxxfb_init(void)
|
| 896 | {
|
| 897 | |
| 898 | * For kernel boot options (in 'video=xxxfb:<options>' format)
|
| 899 |
|
| 900 | #ifndef MODULE
|
| 901 | char *option = NULL;
|
| 902 |
|
| 903 | if (fb_get_options("xxxfb", &option))
|
| 904 | return -ENODEV;
|
| 905 | xxxfb_setup(option);
|
| 906 | #endif
|
| 907 |
|
| 908 | return pci_register_driver(&xxxfb_driver);
|
| 909 | }
|
| 910 |
|
| 911 | static void __exit xxxfb_exit(void)
|
| 912 | {
|
| 913 | pci_unregister_driver(&xxxfb_driver);
|
| 914 | }
|
| 915 | #else
|
| 916 | #include <linux/platform_device.h>
|
| 917 |
|
| 918 |
|
| 919 | #ifdef CONFIG_PM
|
| 920 | |
| 921 | * xxxfb_suspend - Optional but recommended function. Suspend the device.
|
| 922 | * @dev: platform device
|
| 923 | * @msg: the suspend event code.
|
| 924 | *
|
| 925 | * See Documentation/driver-api/pm/devices.rst for more information
|
| 926 |
|
| 927 | static int xxxfb_suspend(struct platform_device *dev, pm_message_t msg)
|
| 928 | {
|
| 929 | struct fb_info *info = platform_get_drvdata(dev);
|
| 930 | struct xxxfb_par *par = info->par;
|
| 931 |
|
| 932 |
|
| 933 | return 0;
|
| 934 | }
|
| 935 |
|
| 936 | |
| 937 | * xxxfb_resume - Optional but recommended function. Resume the device.
|
| 938 | * @dev: platform device
|
| 939 | *
|
| 940 | * See Documentation/driver-api/pm/devices.rst for more information
|
| 941 |
|
| 942 | static int xxxfb_resume(struct platform_dev *dev)
|
| 943 | {
|
| 944 | struct fb_info *info = platform_get_drvdata(dev);
|
| 945 | struct xxxfb_par *par = info->par;
|
| 946 |
|
| 947 |
|
| 948 | return 0;
|
| 949 | }
|
| 950 | #else
|
| 951 | #define xxxfb_suspend NULL
|
| 952 | #define xxxfb_resume NULL
|
| 953 | #endif
|
| 954 |
|
| 955 | static struct platform_device_driver xxxfb_driver = {
|
| 956 | .probe = xxxfb_probe,
|
| 957 | .remove = xxxfb_remove,
|
| 958 | .suspend = xxxfb_suspend,
|
| 959 | .resume = xxxfb_resume,
|
| 960 | .driver = {
|
| 961 | .name = "xxxfb",
|
| 962 | },
|
| 963 | };
|
| 964 |
|
| 965 | static struct platform_device *xxxfb_device;
|
| 966 |
|
| 967 | #ifndef MODULE
|
| 968 | |
| 969 | * Setup
|
| 970 |
|
| 971 |
|
| 972 | |
| 973 | * Only necessary if your driver takes special options,
|
| 974 | * otherwise we fall back on the generic fb_setup().
|
| 975 |
|
| 976 | static int __init xxxfb_setup(char *options)
|
| 977 | {
|
| 978 |
|
| 979 | }
|
| 980 | #endif
|
| 981 |
|
| 982 | static int __init xxxfb_init(void)
|
| 983 | {
|
| 984 | int ret;
|
| 985 | |
| 986 | * For kernel boot options (in 'video=xxxfb:<options>' format)
|
| 987 |
|
| 988 | #ifndef MODULE
|
| 989 | char *option = NULL;
|
| 990 | #endif
|
| 991 |
|
| 992 | if (fb_modesetting_disabled("xxxfb"))
|
| 993 | return -ENODEV;
|
| 994 |
|
| 995 | #ifndef MODULE
|
| 996 | if (fb_get_options("xxxfb", &option))
|
| 997 | return -ENODEV;
|
| 998 | xxxfb_setup(option);
|
| 999 | #endif
|
| 1000 | ret = platform_driver_register(&xxxfb_driver);
|
| 1001 |
|
| 1002 | if (!ret) {
|
| 1003 | xxxfb_device = platform_device_register_simple("xxxfb", 0,
|
| 1004 | NULL, 0);
|
| 1005 |
|
| 1006 | if (IS_ERR(xxxfb_device)) {
|
| 1007 | platform_driver_unregister(&xxxfb_driver);
|
| 1008 | ret = PTR_ERR(xxxfb_device);
|
| 1009 | }
|
| 1010 | }
|
| 1011 |
|
| 1012 | return ret;
|
| 1013 | }
|
| 1014 |
|
| 1015 | static void __exit xxxfb_exit(void)
|
| 1016 | {
|
| 1017 | platform_device_unregister(xxxfb_device);
|
| 1018 | platform_driver_unregister(&xxxfb_driver);
|
| 1019 | }
|
| 1020 | #endif
|
| 1021 |
|
| 1022 |
|
| 1023 |
|
| 1024 |
|
| 1025 | |
| 1026 | * Modularization
|
| 1027 |
|
| 1028 |
|
| 1029 | module_init(xxxfb_init);
|
| 1030 | module_exit(xxxfb_exit);
|
| 1031 |
|
| 1032 | MODULE_LICENSE("GPL");
|