| /Linux-v5.4/drivers/gpu/drm/tiny/ |
| D | repaper.c | 207 u8 pixels = data[b] & 0xaa; in repaper_even_pixels() local
212 pixel_mask = (mask[b] ^ pixels) & 0xaa; in repaper_even_pixels()
218 pixels = 0xaa | ((pixels ^ 0xaa) >> 1); in repaper_even_pixels()
221 pixels = 0x55 + ((pixels ^ 0xaa) >> 1); in repaper_even_pixels()
224 pixels = 0x55 | (pixels ^ 0xaa); in repaper_even_pixels()
227 pixels = 0xaa | (pixels >> 1); in repaper_even_pixels()
231 pixels = (pixels & pixel_mask) | (~pixel_mask & 0x55); in repaper_even_pixels()
232 p1 = (pixels >> 6) & 0x03; in repaper_even_pixels()
233 p2 = (pixels >> 4) & 0x03; in repaper_even_pixels()
234 p3 = (pixels >> 2) & 0x03; in repaper_even_pixels()
[all …]
|
| /Linux-v5.4/drivers/video/fbdev/ |
| D | c2p_iplan2.c | 89 u8 pixels[16]; in c2p_iplan2() member
109 memset(d.pixels, 0, sizeof(d)); in c2p_iplan2()
110 memcpy(d.pixels+dst_idx, c, width); in c2p_iplan2()
121 memset(d.pixels, 0, dst_idx); in c2p_iplan2()
122 memcpy(d.pixels+dst_idx, c, w); in c2p_iplan2()
131 memcpy(d.pixels, c, 16); in c2p_iplan2()
141 memcpy(d.pixels, c, w); in c2p_iplan2()
142 memset(d.pixels+w, 0, 16-w); in c2p_iplan2()
|
| D | c2p_planar.c | 91 u8 pixels[32]; in c2p_planar() member
109 memset(d.pixels, 0, sizeof(d)); in c2p_planar()
110 memcpy(d.pixels+dst_idx, c, width); in c2p_planar()
122 memset(d.pixels, 0, dst_idx); in c2p_planar()
123 memcpy(d.pixels+dst_idx, c, w); in c2p_planar()
133 memcpy(d.pixels, c, 32); in c2p_planar()
143 memcpy(d.pixels, c, w); in c2p_planar()
144 memset(d.pixels+w, 0, 32-w); in c2p_planar()
|
| /Linux-v5.4/Documentation/devicetree/bindings/input/touchscreen/ |
| D | chipone_icn8318.txt | 8 - touchscreen-size-x : horizontal resolution of touchscreen (in pixels)
9 - touchscreen-size-y : vertical resolution of touchscreen (in pixels)
16 device (in pixels)
18 device (in pixels)
|
| D | cyttsp.txt | 18 - touchscreen-size-x : horizontal resolution of touchscreen (in pixels)
19 - touchscreen-size-y : vertical resolution of touchscreen (in pixels)
21 (in pixels)
23 (in pixels)
24 - active-distance : the distance in pixels beyond which a touch must move
|
| D | brcm,iproc-touchscreen.txt | 53 - touchscreen-size-x: horizontal resolution of touchscreen (in pixels)
54 - touchscreen-size-y: vertical resolution of touchscreen (in pixels)
56 device (in pixels)
58 device (in pixels)
|
| D | pixcir_i2c_ts.txt | 8 - touchscreen-size-x: horizontal resolution of touchscreen (in pixels)
9 - touchscreen-size-y: vertical resolution of touchscreen (in pixels)
|
| D | bu21029.txt | 12 - touchscreen-size-x : horizontal resolution of touchscreen (in pixels)
13 - touchscreen-size-y : vertical resolution of touchscreen (in pixels)
|
| /Linux-v5.4/Documentation/media/uapi/v4l/ |
| D | vidioc-cropcap.rst | 51 support cropping and/or scaling and/or have non-square pixels, and for
74 and height are defined in pixels, the driver writer is free to
88 to get square pixels.
90 When cropping coordinates refer to square pixels, the driver sets
118 pixels.
122 pixels.
125 - Width of the rectangle, in pixels.
128 - Height of the rectangle, in pixels.
|
| D | pixfmt-y12i.rst | 23 pixels from 2 sources interleaved and bit-packed. Each pixel is stored
25 these pixels can be deinterlaced using
34 pixels cross the byte boundary and have a ratio of 3 bytes for each
|
| D | selection-api-configuration.rst | 41 in pixels.
58 coordinates are expressed in pixels. The rectangle's top/left corner
77 ``V4L2_SEL_TGT_COMPOSE_PADDED``. It contains all pixels defined using
79 during insertion process. All pixels outside this rectangle *must not*
80 be changed by the hardware. The content of pixels that lie inside the
82 use the padded and active rectangles to detect where the rubbish pixels
98 All coordinates are expressed in pixels. The top/left corner is always
116 target. The rectangle's coordinates are expressed in pixels. The
133 ``V4L2_SEL_TGT_COMPOSE_PADDED`` identifier. It must contain all pixels
|
| D | pixfmt-uyvy.rst | 24 In this format each four bytes is two pixels. Each four bytes is two
25 Y's, a Cb and a Cr. Each Y goes to one of the pixels, and the Cb and Cr
26 belong to both pixels. As you can see, the Cr and Cb components have
|
| D | pixfmt-yvyu.rst | 24 In this format each four bytes is two pixels. Each four bytes is two
25 Y's, a Cb and a Cr. Each Y goes to one of the pixels, and the Cb and Cr
26 belong to both pixels. As you can see, the Cr and Cb components have
|
| D | pixfmt-vyuy.rst | 24 In this format each four bytes is two pixels. Each four bytes is two
25 Y's, a Cb and a Cr. Each Y goes to one of the pixels, and the Cb and Cr
26 belong to both pixels. As you can see, the Cr and Cb components have
|
| D | pixfmt-yuyv.rst | 24 In this format each four bytes is two pixels. Each four bytes is two
25 Y's, a Cb and a Cr. Each Y goes to one of the pixels, and the Cb and Cr
26 belong to both pixels. As you can see, the Cr and Cb components have
|
| D | vidioc-subdev-enum-frame-size.rst | 94 - Minimum frame width, in pixels.
97 - Maximum frame width, in pixels.
100 - Minimum frame height, in pixels.
103 - Maximum frame height, in pixels.
|
| D | pixfmt-y10b.rst | 29 pixels cross the byte boundary and have a ratio of 5 bytes for each 4
30 pixels.
|
| D | pixfmt-y10p.rst | 23 pixel. Every four consecutive pixels are packed into 5 bytes. Each of
24 the first 4 bytes contain the 8 high order bits of the pixels, and
|
| D | pixfmt-nv12m.rst | 36 of the image), but is half as tall in pixels. Each CbCr pair belongs to
37 four pixels. For example, Cb\ :sub:`0`/Cr\ :sub:`0` belongs to
40 ``V4L2_PIX_FMT_NV12M`` with 16x16 macroblock tiles. Here pixels are
|
| D | vidioc-g-fbuf.rst | 129 - Width of the frame buffer in pixels.
133 - Height of the frame buffer in pixels.
170 - Distance in bytes between the leftmost pixels in two adjacent
238 image pixels replace pixels in the VGA or video signal only where
263 - The device supports Source Chroma-keying. Video pixels with the
264 chroma-key colors are replaced by framebuffer pixels, which is
313 framebuffer pixels with video images. The blend function is:
328 framebuffer to clip or blend framebuffer pixels with video images,
|
| /Linux-v5.4/Documentation/devicetree/bindings/display/panel/ |
| D | sharp,lq101r1sx01.txt | 13 pixels and DSI-LINK2 always provides the right/odd pixels. In command mode it
14 is possible to program either link to drive the left/even or right/odd pixels
|
| /Linux-v5.4/Documentation/devicetree/bindings/display/bridge/ |
| D | thine,thc63lvd1024.txt | 32 mode, all pixels are received on port@0, and port@1 shall not contain any
33 endpoint. In dual-link mode, even-numbered pixels are received on port@0 and
34 odd-numbered pixels on port@1, and both port@0 and port@1 shall contain
|
| /Linux-v5.4/drivers/gpu/drm/ |
| D | drm_format_helper.c | 117 unsigned int pixels, in drm_fb_xrgb8888_to_rgb565_line() argument
123 for (x = 0; x < pixels; x++) { in drm_fb_xrgb8888_to_rgb565_line()
220 unsigned int pixels) in drm_fb_xrgb8888_to_rgb888_line() argument
224 for (x = 0; x < pixels; x++) { in drm_fb_xrgb8888_to_rgb888_line()
|
| /Linux-v5.4/Documentation/fb/ |
| D | udlfb.rst | 14 the minimal set of pixels that have changed; and compresses and sends those
15 pixels line-by-line via USB bulk transfers.
81 udlfb to efficiently process the changed pixels.
119 the USB bus in device memory. If any pixels are unchanged,
149 USB to communicate the resulting changed pixels to the
153 above pixels (in thousands of cycles).
|
| /Linux-v5.4/drivers/gpu/drm/vboxvideo/ |
| D | hgsmi_base.c | 115 u8 *pixels, u32 len) in hgsmi_update_pointer_shape() argument
150 memcpy(p->data, pixels, pixel_len); in hgsmi_update_pointer_shape()
|
