Skip to content

Commit

Permalink
---
Browse files Browse the repository at this point in the history
yaml
---
r: 197118
b: refs/heads/master
c: 3b7b31f
h: refs/heads/master
v: v3
  • Loading branch information
Pavel Machek authored and Greg Kroah-Hartman committed May 11, 2010
1 parent 2e5cc81 commit eb4e277
Show file tree
Hide file tree
Showing 2 changed files with 30 additions and 30 deletions.
2 changes: 1 addition & 1 deletion [refs]
Original file line number Diff line number Diff line change
@@ -1,2 +1,2 @@
---
refs/heads/master: 593ef41c95c82a7c8d09c28db4893f4dd2ff0134
refs/heads/master: 3b7b31fa7df01576cc401dff512a6a84cb3753ed
58 changes: 29 additions & 29 deletions trunk/drivers/staging/udlfb/udlfb.c
Original file line number Diff line number Diff line change
Expand Up @@ -58,17 +58,17 @@ static struct usb_device_id id_table[] = {
MODULE_DEVICE_TABLE(usb, id_table);

#ifndef CONFIG_FB_DEFERRED_IO
#warning message "kernel FB_DEFFERRED_IO option to support generic fbdev apps"
#warning Please set CONFIG_FB_DEFFERRED_IO option to support generic fbdev apps
#endif

#ifndef CONFIG_FB_SYS_IMAGEBLIT
#ifndef CONFIG_FB_SYS_IMAGEBLIT_MODULE
#warning message "FB_SYS_* in kernel or module option to support fb console"
#warning Please set CONFIG_FB_SYS_IMAGEBLIT option to support fb console
#endif
#endif

#ifndef CONFIG_FB_MODE_HELPERS
#warning message "kernel FB_MODE_HELPERS required. Expect build break"
#warning CONFIG_FB_MODE_HELPERS required. Expect build break
#endif

/* dlfb keeps a list of urbs for efficient bulk transfers */
Expand Down Expand Up @@ -366,32 +366,32 @@ static int dlfb_trim_hline(const u8 *bback, const u8 **bfront, int *width_bytes)
}

/*
Render a command stream for an encoded horizontal line segment of pixels.
A command buffer holds several commands.
It always begins with a fresh command header
(the protocol doesn't require this, but we enforce it to allow
multiple buffers to be potentially encoded and sent in parallel).
A single command encodes one contiguous horizontal line of pixels
The function relies on the client to do all allocation, so that
rendering can be done directly to output buffers (e.g. USB URBs).
The function fills the supplied command buffer, providing information
on where it left off, so the client may call in again with additional
buffers if the line will take several buffers to complete.
A single command can transmit a maximum of 256 pixels,
regardless of the compression ratio (protocol design limit).
To the hardware, 0 for a size byte means 256
Rather than 256 pixel commands which are either rl or raw encoded,
the rlx command simply assumes alternating raw and rl spans within one cmd.
This has a slightly larger header overhead, but produces more even results.
It also processes all data (read and write) in a single pass.
Performance benchmarks of common cases show it having just slightly better
compression than 256 pixel raw -or- rle commands, with similar CPU consumpion.
But for very rl friendly data, will compress not quite as well.
*/
* Render a command stream for an encoded horizontal line segment of pixels.
*
* A command buffer holds several commands.
* It always begins with a fresh command header
* (the protocol doesn't require this, but we enforce it to allow
* multiple buffers to be potentially encoded and sent in parallel).
* A single command encodes one contiguous horizontal line of pixels
*
* The function relies on the client to do all allocation, so that
* rendering can be done directly to output buffers (e.g. USB URBs).
* The function fills the supplied command buffer, providing information
* on where it left off, so the client may call in again with additional
* buffers if the line will take several buffers to complete.
*
* A single command can transmit a maximum of 256 pixels,
* regardless of the compression ratio (protocol design limit).
* To the hardware, 0 for a size byte means 256
*
* Rather than 256 pixel commands which are either rl or raw encoded,
* the rlx command simply assumes alternating raw and rl spans within one cmd.
* This has a slightly larger header overhead, but produces more even results.
* It also processes all data (read and write) in a single pass.
* Performance benchmarks of common cases show it having just slightly better
* compression than 256 pixel raw -or- rle commands, with similar CPU consumpion.
* But for very rl friendly data, will compress not quite as well.
*/
static void dlfb_compress_hline(
const uint16_t **pixel_start_ptr,
const uint16_t *const pixel_end,
Expand Down

0 comments on commit eb4e277

Please sign in to comment.