skeletonfb.c 34 KB

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