Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux

V4L/DVB (3599c): Whitespace cleanups under Documentation/video4linux

Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>

+172 -172
+91 -91
Documentation/video4linux/CQcam.txt
··· 1 1 c-qcam - Connectix Color QuickCam video4linux kernel driver 2 2 3 3 Copyright (C) 1999 Dave Forrest <drf5n@virginia.edu> 4 - released under GNU GPL. 4 + released under GNU GPL. 5 5 6 6 1999-12-08 Dave Forrest, written with kernel version 2.2.12 in mind 7 7 ··· 45 45 CONFIG_PNP_PARPORT M for autoprobe.o IEEE1284 readback module 46 46 CONFIG_PRINTER_READBACK M for parport_probe.o IEEE1284 readback module 47 47 CONFIG_VIDEO_DEV M for videodev.o video4linux module 48 - CONFIG_VIDEO_CQCAM M for c-qcam.o Color Quickcam module 48 + CONFIG_VIDEO_CQCAM M for c-qcam.o Color Quickcam module 49 49 50 50 With these flags, the kernel should compile and install the modules. 51 51 To record and monitor the compilation, I use: 52 52 53 53 (make zlilo ; \ 54 54 make modules; \ 55 - make modules_install ; 55 + make modules_install ; 56 56 depmod -a ) &>log & 57 57 less log # then a capital 'F' to watch the progress 58 - 58 + 59 59 But that is my personal preference. 60 60 61 61 2.2 Configuration 62 - 62 + 63 63 The configuration requires module configuration and device 64 64 configuration. I like kmod or kerneld process with the 65 65 /etc/modprobe.conf file so the modules can automatically load/unload as ··· 68 68 these procedures. 69 69 70 70 71 - 2.1 Module Configuration 71 + 2.1 Module Configuration 72 72 73 73 Using modules requires a bit of work to install and pass the 74 74 parameters. Understand that entries in /etc/modprobe.conf of: ··· 128 128 (CONFIG_PRINTER), the IEEE 1284 system,(CONFIG_PRINTER_READBACK), you 129 129 should be able to read some identification from your quickcam with 130 130 131 - modprobe -v parport 132 - modprobe -v parport_probe 133 - cat /proc/parport/PORTNUMBER/autoprobe 131 + modprobe -v parport 132 + modprobe -v parport_probe 133 + cat /proc/parport/PORTNUMBER/autoprobe 134 134 Returns: 135 135 CLASS:MEDIA; 136 136 MODEL:Color QuickCam 2.0; ··· 140 140 and well. A common problem is that the current driver does not 141 141 reliably detect a c-qcam, even though one is attached. In this case, 142 142 143 - modprobe -v c-qcam 143 + modprobe -v c-qcam 144 144 or 145 145 insmod -v c-qcam 146 146 ··· 152 152 3.1 Checklist: 153 153 154 154 Can you get an image? 155 - v4lgrab >qcam.ppm ; wc qcam.ppm ; xv qcam.ppm 155 + v4lgrab >qcam.ppm ; wc qcam.ppm ; xv qcam.ppm 156 156 157 - Is a working c-qcam connected to the port? 158 - grep ^ /proc/parport/?/autoprobe 157 + Is a working c-qcam connected to the port? 158 + grep ^ /proc/parport/?/autoprobe 159 159 160 - Do the /dev/video* files exist? 161 - ls -lad /dev/video 160 + Do the /dev/video* files exist? 161 + ls -lad /dev/video 162 162 163 - Is the c-qcam module loaded? 164 - modprobe -v c-qcam ; lsmod 163 + Is the c-qcam module loaded? 164 + modprobe -v c-qcam ; lsmod 165 165 166 166 Does the camera work with alternate programs? cqcam, etc? 167 167 ··· 174 174 isn't, you might try patching the c-qcam module to add a parport=xxx 175 175 option as in the bw-qcam module so you can specify the parallel port: 176 176 177 - insmod -v c-qcam parport=0 177 + insmod -v c-qcam parport=0 178 178 179 179 And bypass the detection code, see ../../drivers/char/c-qcam.c and 180 180 look for the 'qc_detect' code and call. ··· 183 183 this work is documented at the video4linux2 site listed below. 184 184 185 185 186 - 9.0 --- A sample program using v4lgrabber, 186 + 9.0 --- A sample program using v4lgrabber, 187 187 188 188 This program is a simple image grabber that will copy a frame from the 189 189 first video device, /dev/video0 to standard output in portable pixmap 190 190 format (.ppm) Using this like: 'v4lgrab | convert - c-qcam.jpg' 191 - produced this picture of me at 191 + produced this picture of me at 192 192 http://mug.sys.virginia.edu/~drf5n/extras/c-qcam.jpg 193 193 194 194 -------------------- 8< ---------------- 8< ----------------------------- ··· 202 202 * Use as: 203 203 * v4lgrab >image.ppm 204 204 * 205 - * Copyright (C) 1998-05-03, Phil Blundell <philb@gnu.org> 206 - * Copied from http://www.tazenda.demon.co.uk/phil/vgrabber.c 205 + * Copyright (C) 1998-05-03, Phil Blundell <philb@gnu.org> 206 + * Copied from http://www.tazenda.demon.co.uk/phil/vgrabber.c 207 207 * with minor modifications (Dave Forrest, drf5n@virginia.edu). 208 208 * 209 209 */ ··· 225 225 226 226 #define READ_VIDEO_PIXEL(buf, format, depth, r, g, b) \ 227 227 { \ 228 - switch (format) \ 229 - { \ 230 - case VIDEO_PALETTE_GREY: \ 231 - switch (depth) \ 232 - { \ 233 - case 4: \ 234 - case 6: \ 235 - case 8: \ 236 - (r) = (g) = (b) = (*buf++ << 8);\ 237 - break; \ 238 - \ 239 - case 16: \ 240 - (r) = (g) = (b) = \ 241 - *((unsigned short *) buf); \ 242 - buf += 2; \ 243 - break; \ 244 - } \ 245 - break; \ 246 - \ 247 - \ 248 - case VIDEO_PALETTE_RGB565: \ 249 - { \ 250 - unsigned short tmp = *(unsigned short *)buf; \ 251 - (r) = tmp&0xF800; \ 252 - (g) = (tmp<<5)&0xFC00; \ 253 - (b) = (tmp<<11)&0xF800; \ 254 - buf += 2; \ 255 - } \ 256 - break; \ 257 - \ 258 - case VIDEO_PALETTE_RGB555: \ 259 - (r) = (buf[0]&0xF8)<<8; \ 260 - (g) = ((buf[0] << 5 | buf[1] >> 3)&0xF8)<<8; \ 261 - (b) = ((buf[1] << 2 ) & 0xF8)<<8; \ 262 - buf += 2; \ 263 - break; \ 264 - \ 265 - case VIDEO_PALETTE_RGB24: \ 266 - (r) = buf[0] << 8; (g) = buf[1] << 8; \ 267 - (b) = buf[2] << 8; \ 268 - buf += 3; \ 269 - break; \ 270 - \ 271 - default: \ 272 - fprintf(stderr, \ 273 - "Format %d not yet supported\n", \ 274 - format); \ 275 - } \ 276 - } 228 + switch (format) \ 229 + { \ 230 + case VIDEO_PALETTE_GREY: \ 231 + switch (depth) \ 232 + { \ 233 + case 4: \ 234 + case 6: \ 235 + case 8: \ 236 + (r) = (g) = (b) = (*buf++ << 8);\ 237 + break; \ 238 + \ 239 + case 16: \ 240 + (r) = (g) = (b) = \ 241 + *((unsigned short *) buf); \ 242 + buf += 2; \ 243 + break; \ 244 + } \ 245 + break; \ 246 + \ 247 + \ 248 + case VIDEO_PALETTE_RGB565: \ 249 + { \ 250 + unsigned short tmp = *(unsigned short *)buf; \ 251 + (r) = tmp&0xF800; \ 252 + (g) = (tmp<<5)&0xFC00; \ 253 + (b) = (tmp<<11)&0xF800; \ 254 + buf += 2; \ 255 + } \ 256 + break; \ 257 + \ 258 + case VIDEO_PALETTE_RGB555: \ 259 + (r) = (buf[0]&0xF8)<<8; \ 260 + (g) = ((buf[0] << 5 | buf[1] >> 3)&0xF8)<<8; \ 261 + (b) = ((buf[1] << 2 ) & 0xF8)<<8; \ 262 + buf += 2; \ 263 + break; \ 264 + \ 265 + case VIDEO_PALETTE_RGB24: \ 266 + (r) = buf[0] << 8; (g) = buf[1] << 8; \ 267 + (b) = buf[2] << 8; \ 268 + buf += 3; \ 269 + break; \ 270 + \ 271 + default: \ 272 + fprintf(stderr, \ 273 + "Format %d not yet supported\n", \ 274 + format); \ 275 + } \ 276 + } 277 277 278 278 int get_brightness_adj(unsigned char *image, long size, int *brightness) { 279 279 long i, tot = 0; ··· 324 324 if(ioctl(fd, VIDIOCSPICT, &vpic) < 0) { 325 325 vpic.depth=6; 326 326 if(ioctl(fd, VIDIOCSPICT, &vpic) < 0) { 327 - vpic.depth=4; 328 - if(ioctl(fd, VIDIOCSPICT, &vpic) < 0) { 329 - fprintf(stderr, "Unable to find a supported capture format.\n"); 330 - close(fd); 331 - exit(1); 332 - } 327 + vpic.depth=4; 328 + if(ioctl(fd, VIDIOCSPICT, &vpic) < 0) { 329 + fprintf(stderr, "Unable to find a supported capture format.\n"); 330 + close(fd); 331 + exit(1); 332 + } 333 333 } 334 334 } 335 335 } else { 336 336 vpic.depth=24; 337 337 vpic.palette=VIDEO_PALETTE_RGB24; 338 - 338 + 339 339 if(ioctl(fd, VIDIOCSPICT, &vpic) < 0) { 340 340 vpic.palette=VIDEO_PALETTE_RGB565; 341 341 vpic.depth=16; 342 - 342 + 343 343 if(ioctl(fd, VIDIOCSPICT, &vpic)==-1) { 344 - vpic.palette=VIDEO_PALETTE_RGB555; 345 - vpic.depth=15; 346 - 347 - if(ioctl(fd, VIDIOCSPICT, &vpic)==-1) { 348 - fprintf(stderr, "Unable to find a supported capture format.\n"); 349 - return -1; 350 - } 344 + vpic.palette=VIDEO_PALETTE_RGB555; 345 + vpic.depth=15; 346 + 347 + if(ioctl(fd, VIDIOCSPICT, &vpic)==-1) { 348 + fprintf(stderr, "Unable to find a supported capture format.\n"); 349 + return -1; 350 + } 351 351 } 352 352 } 353 353 } 354 - 354 + 355 355 buffer = malloc(win.width * win.height * bpp); 356 356 if (!buffer) { 357 357 fprintf(stderr, "Out of memory.\n"); 358 358 exit(1); 359 359 } 360 - 360 + 361 361 do { 362 362 int newbright; 363 363 read(fd, buffer, win.width * win.height * bpp); ··· 365 365 if (f) { 366 366 vpic.brightness += (newbright << 8); 367 367 if(ioctl(fd, VIDIOCSPICT, &vpic)==-1) { 368 - perror("VIDIOSPICT"); 369 - break; 368 + perror("VIDIOSPICT"); 369 + break; 370 370 } 371 371 } 372 372 } while (f); ··· 381 381 fputc(g>>8, stdout); 382 382 fputc(b>>8, stdout); 383 383 } 384 - 384 + 385 385 close(fd); 386 386 return 0; 387 387 }
+2 -2
Documentation/video4linux/README.cpia
··· 87 87 at the LILO-prompt or specify it in lilo.conf. I use the following 88 88 append-line in lilo.conf: 89 89 90 - append="parport=0x378,7,3" 90 + append="parport=0x378,7,3" 91 91 92 92 See Documentation/parport.txt for more information about the 93 93 configuration of the parport and the values given above. Do not simply ··· 175 175 - Manuel J. Petit de Gabriel <mpetit@dit.upm.es> for providing help 176 176 with Isabel (http://isabel.dit.upm.es/) 177 177 - Bas Huisman <bhuism@cs.utwente.nl> for writing the initial parport code 178 - - Jarl Totland <Jarl.Totland@bdc.no> for setting up the mailing list 178 + - Jarl Totland <Jarl.Totland@bdc.no> for setting up the mailing list 179 179 and maintaining the web-server[3] 180 180 - Chris Whiteford <Chris@informinteractive.com> for fixes related to the 181 181 1.02 firmware
+54 -54
Documentation/video4linux/Zoran
··· 28 28 * Philips saa7111 TV decoder 29 29 * Philips saa7185 TV encoder 30 30 Drivers to use: videodev, i2c-core, i2c-algo-bit, 31 - videocodec, saa7111, saa7185, zr36060, zr36067 31 + videocodec, saa7111, saa7185, zr36060, zr36067 32 32 Inputs/outputs: Composite and S-video 33 33 Norms: PAL, SECAM (720x576 @ 25 fps), NTSC (720x480 @ 29.97 fps) 34 34 Card number: 7 ··· 39 39 * Brooktree bt819 TV decoder 40 40 * Brooktree bt856 TV encoder 41 41 Drivers to use: videodev, i2c-core, i2c-algo-bit, 42 - videocodec, bt819, bt856, zr36060, zr36067 42 + videocodec, bt819, bt856, zr36060, zr36067 43 43 Inputs/outputs: Composite and S-video 44 44 Norms: PAL (720x576 @ 25 fps), NTSC (720x480 @ 29.97 fps) 45 45 Card number: 5 ··· 50 50 * Philips saa7114 TV decoder 51 51 * Analog Devices adv7170 TV encoder 52 52 Drivers to use: videodev, i2c-core, i2c-algo-bit, 53 - videocodec, saa7114, adv7170, zr36060, zr36067 53 + videocodec, saa7114, adv7170, zr36060, zr36067 54 54 Inputs/outputs: Composite and S-video 55 55 Norms: PAL (720x576 @ 25 fps), NTSC (720x480 @ 29.97 fps) 56 56 Card number: 6 ··· 61 61 * Philips saa7110a TV decoder 62 62 * Analog Devices adv7176 TV encoder 63 63 Drivers to use: videodev, i2c-core, i2c-algo-bit, 64 - videocodec, saa7110, adv7175, zr36060, zr36067 64 + videocodec, saa7110, adv7175, zr36060, zr36067 65 65 Inputs/outputs: Composite, S-video and Internal 66 66 Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps) 67 67 Card number: 1 ··· 84 84 * Micronas vpx3220a TV decoder 85 85 * mse3000 TV encoder or Analog Devices adv7176 TV encoder * 86 86 Drivers to use: videodev, i2c-core, i2c-algo-bit, 87 - videocodec, vpx3220, mse3000/adv7175, zr36050, zr36016, zr36067 87 + videocodec, vpx3220, mse3000/adv7175, zr36050, zr36016, zr36067 88 88 Inputs/outputs: Composite, S-video and Internal 89 89 Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps) 90 90 Card number: 0 ··· 96 96 * Micronas vpx3225d/vpx3220a/vpx3216b TV decoder 97 97 * Analog Devices adv7176 TV encoder 98 98 Drivers to use: videodev, i2c-core, i2c-algo-bit, 99 - videocodec, vpx3220/vpx3224, adv7175, zr36050, zr36016, zr36067 99 + videocodec, vpx3220/vpx3224, adv7175, zr36050, zr36016, zr36067 100 100 Inputs/outputs: Composite, S-video and Internal 101 101 Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps) 102 102 Card number: 3 ··· 123 123 124 124 The best know TV standards are NTSC/PAL/SECAM. but for decoding a frame that 125 125 information is not enough. There are several formats of the TV standards. 126 - And not every TV decoder is able to handle every format. Also the every 127 - combination is supported by the driver. There are currently 11 different 128 - tv broadcast formats all aver the world. 126 + And not every TV decoder is able to handle every format. Also the every 127 + combination is supported by the driver. There are currently 11 different 128 + tv broadcast formats all aver the world. 129 129 130 - The CCIR defines parameters needed for broadcasting the signal. 130 + The CCIR defines parameters needed for broadcasting the signal. 131 131 The CCIR has defined different standards: A,B,D,E,F,G,D,H,I,K,K1,L,M,N,... 132 132 The CCIR says not much about about the colorsystem used !!! 133 133 And talking about a colorsystem says not to much about how it is broadcast. ··· 136 136 137 137 When you speak about NTSC, you usually mean the standard: CCIR - M using 138 138 the NTSC colorsystem which is used in the USA, Japan, Mexico, Canada 139 - and a few others. 139 + and a few others. 140 140 141 141 When you talk about PAL, you usually mean: CCIR - B/G using the PAL 142 - colorsystem which is used in many Countries. 142 + colorsystem which is used in many Countries. 143 143 144 - When you talk about SECAM, you mean: CCIR - L using the SECAM Colorsystem 144 + When you talk about SECAM, you mean: CCIR - L using the SECAM Colorsystem 145 145 which is used in France, and a few others. 146 146 147 147 There the other version of SECAM, CCIR - D/K is used in Bulgaria, China, 148 - Slovakai, Hungary, Korea (Rep.), Poland, Rumania and a others. 148 + Slovakai, Hungary, Korea (Rep.), Poland, Rumania and a others. 149 149 150 - The CCIR - H uses the PAL colorsystem (sometimes SECAM) and is used in 150 + The CCIR - H uses the PAL colorsystem (sometimes SECAM) and is used in 151 151 Egypt, Libya, Sri Lanka, Syrain Arab. Rep. 152 152 153 153 The CCIR - I uses the PAL colorsystem, and is used in Great Britain, Hong Kong, ··· 158 158 159 159 We do not talk about how the audio is broadcast ! 160 160 161 - A rather good sites about the TV standards are: 161 + A rather good sites about the TV standards are: 162 162 http://www.sony.jp/ServiceArea/Voltage_map/ 163 163 http://info.electronicwerkstatt.de/bereiche/fernsehtechnik/frequenzen_und_normen/Fernsehnormen/ 164 164 and http://www.cabl.com/restaurant/channel.html 165 165 166 166 Other weird things around: NTSC 4.43 is a modificated NTSC, which is mainly 167 167 used in PAL VCR's that are able to play back NTSC. PAL 60 seems to be the same 168 - as NTSC 4.43 . The Datasheets also talk about NTSC 44, It seems as if it would 169 - be the same as NTSC 4.43. 168 + as NTSC 4.43 . The Datasheets also talk about NTSC 44, It seems as if it would 169 + be the same as NTSC 4.43. 170 170 NTSC Combs seems to be a decoder mode where the decoder uses a comb filter 171 171 to split coma and luma instead of a Delay line. 172 172 173 173 But I did not defiantly find out what NTSC Comb is. 174 174 175 175 Philips saa7111 TV decoder 176 - was introduced in 1997, is used in the BUZ and 177 - can handle: PAL B/G/H/I, PAL N, PAL M, NTSC M, NTSC N, NTSC 4.43 and SECAM 176 + was introduced in 1997, is used in the BUZ and 177 + can handle: PAL B/G/H/I, PAL N, PAL M, NTSC M, NTSC N, NTSC 4.43 and SECAM 178 178 179 179 Philips saa7110a TV decoder 180 180 was introduced in 1995, is used in the Pinnacle/Miro DC10(new), DC10+ and 181 - can handle: PAL B/G, NTSC M and SECAM 181 + can handle: PAL B/G, NTSC M and SECAM 182 182 183 183 Philips saa7114 TV decoder 184 - was introduced in 2000, is used in the LML33R10 and 184 + was introduced in 2000, is used in the LML33R10 and 185 185 can handle: PAL B/G/D/H/I/N, PAL N, PAL M, NTSC M, NTSC 4.43 and SECAM 186 186 187 187 Brooktree bt819 TV decoder ··· 206 206 can generate: PAL B/G, NTSC M 207 207 208 208 Brooktree bt856 TV Encoder 209 - was introduced in 1994, is used in the LML33 209 + was introduced in 1994, is used in the LML33 210 210 can generate: PAL B/D/G/H/I/N, PAL M, NTSC M, PAL-N (Argentina) 211 211 212 212 Analog Devices adv7170 TV Encoder ··· 221 221 was introduced in 1991, is used in the DC10 old 222 222 can generate: PAL , NTSC , SECAM 223 223 224 - The adv717x, should be able to produce PAL N. But you find nothing PAL N 224 + The adv717x, should be able to produce PAL N. But you find nothing PAL N 225 225 specific in the registers. Seem that you have to reuse a other standard 226 - to generate PAL N, maybe it would work if you use the PAL M settings. 226 + to generate PAL N, maybe it would work if you use the PAL M settings. 227 227 228 228 ========================== 229 229 ··· 261 261 262 262 VIA MVP3 263 263 Forget it. Pointless. Doesn't work. 264 - Intel 430FX (Pentium 200) 264 + Intel 430FX (Pentium 200) 265 265 LML33 perfect, Buz tolerable (3 or 4 frames dropped per movie) 266 266 Intel 440BX (early stepping) 267 267 LML33 tolerable. Buz starting to get annoying (6-10 frames/hour) ··· 438 438 > -q 25 -b 128 : 24.655.992 439 439 > -q 25 -b 256 : 25.859.820 440 440 441 - I woke up, and can't go to sleep again. I'll kill some time explaining why 441 + I woke up, and can't go to sleep again. I'll kill some time explaining why 442 442 this doesn't look strange to me. 443 443 444 - Let's do some math using a width of 704 pixels. I'm not sure whether the Buz 444 + Let's do some math using a width of 704 pixels. I'm not sure whether the Buz 445 445 actually use that number or not, but that's not too important right now. 446 446 447 - 704x288 pixels, one field, is 202752 pixels. Divided by 64 pixels per block; 448 - 3168 blocks per field. Each pixel consist of two bytes; 128 bytes per block; 449 - 1024 bits per block. 100% in the new driver mean 1:2 compression; the maximum 450 - output becomes 512 bits per block. Actually 510, but 512 is simpler to use 447 + 704x288 pixels, one field, is 202752 pixels. Divided by 64 pixels per block; 448 + 3168 blocks per field. Each pixel consist of two bytes; 128 bytes per block; 449 + 1024 bits per block. 100% in the new driver mean 1:2 compression; the maximum 450 + output becomes 512 bits per block. Actually 510, but 512 is simpler to use 451 451 for calculations. 452 452 453 - Let's say that we specify d1q50. We thus want 256 bits per block; times 3168 454 - becomes 811008 bits; 101376 bytes per field. We're talking raw bits and bytes 455 - here, so we don't need to do any fancy corrections for bits-per-pixel or such 453 + Let's say that we specify d1q50. We thus want 256 bits per block; times 3168 454 + becomes 811008 bits; 101376 bytes per field. We're talking raw bits and bytes 455 + here, so we don't need to do any fancy corrections for bits-per-pixel or such 456 456 things. 101376 bytes per field. 457 457 458 - d1 video contains two fields per frame. Those sum up to 202752 bytes per 458 + d1 video contains two fields per frame. Those sum up to 202752 bytes per 459 459 frame, and one of those frames goes into each buffer. 460 460 461 - But wait a second! -b128 gives 128kB buffers! It's not possible to cram 461 + But wait a second! -b128 gives 128kB buffers! It's not possible to cram 462 462 202752 bytes of JPEG data into 128kB! 463 463 464 - This is what the driver notice and automatically compensate for in your 464 + This is what the driver notice and automatically compensate for in your 465 465 examples. Let's do some math using this information: 466 466 467 - 128kB is 131072 bytes. In this buffer, we want to store two fields, which 468 - leaves 65536 bytes for each field. Using 3168 blocks per field, we get 469 - 20.68686868... available bytes per block; 165 bits. We can't allow the 470 - request for 256 bits per block when there's only 165 bits available! The -q50 471 - option is silently overridden, and the -b128 option takes precedence, leaving 467 + 128kB is 131072 bytes. In this buffer, we want to store two fields, which 468 + leaves 65536 bytes for each field. Using 3168 blocks per field, we get 469 + 20.68686868... available bytes per block; 165 bits. We can't allow the 470 + request for 256 bits per block when there's only 165 bits available! The -q50 471 + option is silently overridden, and the -b128 option takes precedence, leaving 472 472 us with the equivalence of -q32. 473 473 474 - This gives us a data rate of 165 bits per block, which, times 3168, sums up 475 - to 65340 bytes per field, out of the allowed 65536. The current driver has 476 - another level of rate limiting; it won't accept -q values that fill more than 477 - 6/8 of the specified buffers. (I'm not sure why. "Playing it safe" seem to be 478 - a safe bet. Personally, I think I would have lowered requested-bits-per-block 479 - by one, or something like that.) We can't use 165 bits per block, but have to 480 - lower it again, to 6/8 of the available buffer space: We end up with 124 bits 481 - per block, the equivalence of -q24. With 128kB buffers, you can't use greater 474 + This gives us a data rate of 165 bits per block, which, times 3168, sums up 475 + to 65340 bytes per field, out of the allowed 65536. The current driver has 476 + another level of rate limiting; it won't accept -q values that fill more than 477 + 6/8 of the specified buffers. (I'm not sure why. "Playing it safe" seem to be 478 + a safe bet. Personally, I think I would have lowered requested-bits-per-block 479 + by one, or something like that.) We can't use 165 bits per block, but have to 480 + lower it again, to 6/8 of the available buffer space: We end up with 124 bits 481 + per block, the equivalence of -q24. With 128kB buffers, you can't use greater 482 482 than -q24 at -d1. (And PAL, and 704 pixels width...) 483 483 484 - The third example is limited to -q24 through the same process. The second 485 - example, using very similar calculations, is limited to -q48. The only 486 - example that actually grab at the specified -q value is the last one, which 484 + The third example is limited to -q24 through the same process. The second 485 + example, using very similar calculations, is limited to -q48. The only 486 + example that actually grab at the specified -q value is the last one, which 487 487 is clearly visible, looking at the file size. 488 488 -- 489 489
+2 -2
Documentation/video4linux/bttv/ICs
··· 14 14 15 15 Microchip 24LC02B or 16 16 Philips 8582E2Y: 256 Byte EEPROM with configuration information 17 - I2C 0xa0-0xa1, (24LC02B also responds to 0xa2-0xaf) 17 + I2C 0xa0-0xa1, (24LC02B also responds to 0xa2-0xaf) 18 18 Philips SAA5246AGP/E: Videotext decoder chip, I2C 0x22-0x23 19 19 TDA9800: sound decoder 20 20 Winbond W24257AS-35: 32Kx8 CMOS static RAM (Videotext buffer mem) 21 21 14052B: analog switch for selection of sound source 22 22 23 - PAL: 23 + PAL: 24 24 TDA5737: VHF, hyperband and UHF mixer/oscillator for TV and VCR 3-band tuners 25 25 TSA5522: 1.4 GHz I2C-bus controlled synthesizer, I2C 0xc2-0xc3 26 26
+8 -8
Documentation/video4linux/bttv/PROBLEMS
··· 3 3 - Start capturing by pressing "c" or by selecting it via a menu!!! 4 4 5 5 - The memory of some S3 cards is not recognized right: 6 - 6 + 7 7 First of all, if you are not using XFree-3.2 or newer, upgrade AT LEAST to 8 8 XFree-3.2A! This solved the problem for most people. 9 9 ··· 31 31 (mostly with Trio 64 but also with some others) 32 32 Get the free demo version of Accelerated X from www.xinside.com and try 33 33 bttv with it. bttv seems to work with most S3 cards with Accelerated X. 34 - 34 + 35 35 Since I do not know much (better make that almost nothing) about VGA card 36 36 programming I do not know the reason for this. 37 37 Looks like XFree does something different when setting up the video memory? 38 - Maybe somebody can enlighten me? 39 - Would be nice if somebody could get this to work with XFree since 40 - Accelerated X costs more than some of the grabber cards ... 41 - 38 + Maybe somebody can enlighten me? 39 + Would be nice if somebody could get this to work with XFree since 40 + Accelerated X costs more than some of the grabber cards ... 41 + 42 42 Better linear frame buffer support for S3 cards will probably be in 43 43 XFree 4.0. 44 - 44 + 45 45 - Grabbing is not switched off when changing consoles with XFree. 46 46 That's because XFree and some AcceleratedX versions do not send unmap 47 47 events. 48 48 49 49 - Some popup windows (e.g. of the window manager) are not refreshed. 50 - 50 + 51 51 Disable backing store by starting X with the option "-bs" 52 52 53 53 - When using 32 bpp in XFree or 24+8bpp mode in AccelX 3.1 the system
+2 -2
Documentation/video4linux/bttv/README.quirks
··· 38 38 ------------------------ 39 39 40 40 When using the 430FX PCI, the following rules will ensure 41 - compatibility: 41 + compatibility: 42 42 43 - (1) Deassert REQ at the same time as asserting FRAME. 43 + (1) Deassert REQ at the same time as asserting FRAME. 44 44 (2) Do not reassert REQ to request another bus transaction until after 45 45 finish-ing the previous transaction. 46 46
+2 -2
Documentation/video4linux/bttv/THANKS
··· 1 1 Many thanks to: 2 2 3 - - Markus Schroeder <schroedm@uni-duesseldorf.de> for information on the Bt848 3 + - Markus Schroeder <schroedm@uni-duesseldorf.de> for information on the Bt848 4 4 and tuner programming and his control program xtvc. 5 5 6 6 - Martin Buck <martin-2.buck@student.uni-ulm.de> for his great Videotext ··· 16 16 - MIRO for providing a free PCTV card and detailed information about the 17 17 components on their cards. (E.g. how the tuner type is detected) 18 18 Without their card I could not have debugged the NTSC mode. 19 - 19 + 20 20 - Hauppauge for telling how the sound input is selected and what components 21 21 they do and will use on their radio cards. 22 22 Also many thanks for faxing me the FM1216 data sheet.
+8 -8
Documentation/video4linux/radiotrack.txt
··· 131 131 x=0xff ==> "not stereo", x=0xfd ==> "stereo detected" 132 132 133 133 Set Frequency: code = (freq*40) + 10486188 134 - foreach of the 24 bits in code, 135 - (from Least to Most Significant): 136 - to write a "zero" bit, 137 - BASE <-- 0x01 (audio mute, no stereo detect, radio 134 + foreach of the 24 bits in code, 135 + (from Least to Most Significant): 136 + to write a "zero" bit, 137 + BASE <-- 0x01 (audio mute, no stereo detect, radio 138 138 disable, "zero" bit phase 1, tuner adjust) 139 - BASE <-- 0x03 (audio mute, no stereo detect, radio 139 + BASE <-- 0x03 (audio mute, no stereo detect, radio 140 140 disable, "zero" bit phase 2, tuner adjust) 141 - to write a "one" bit, 142 - BASE <-- 0x05 (audio mute, no stereo detect, radio 141 + to write a "one" bit, 142 + BASE <-- 0x05 (audio mute, no stereo detect, radio 143 143 disable, "one" bit phase 1, tuner adjust) 144 - BASE <-- 0x07 (audio mute, no stereo detect, radio 144 + BASE <-- 0x07 (audio mute, no stereo detect, radio 145 145 disable, "one" bit phase 2, tuner adjust) 146 146 147 147 ----------------------------------------------------------------------------
+1 -1
Documentation/video4linux/w9966.txt
··· 26 26 A minimal test application (with source) is available from: 27 27 http://hem.fyristorg.com/mogul/w9966.html 28 28 29 - The slow framerate is due to missing DMA ECP read support in the 29 + The slow framerate is due to missing DMA ECP read support in the 30 30 parport drivers. I might add working EPP support later. 31 31 32 32 Good luck!
+2 -2
Documentation/video4linux/zr36120.txt
··· 2 2 ------ --- ----- -------- -------- ------------ ------- - - - 3 3 4 4 - ZORAN ------------------------------------------------------ 5 - Author: Pauline Middelink <middelin@polyware.nl> 5 + Author: Pauline Middelink <middelin@polyware.nl> 6 6 Date: 18 September 1999 7 7 Version: 0.6.1 8 8 ··· 115 115 <n> is the cardtype of the card you have. The cardnumber can 116 116 be found in the source of zr36120. Look for tvcards. If your 117 117 card is not there, please try if any other card gives some 118 - response, and mail me if you got a working tvcard addition. 118 + response, and mail me if you got a working tvcard addition. 119 119 120 120 PS. <TVCard editors behold!) 121 121 Dont forget to set video_input to the number of inputs