- 06 12月, 2009 4 次提交
-
-
由 Mauro Carvalho Chehab 提交于
Adds support to VC211A em2800 card. As this board doesn't have eeprom, and uses a common set of i2c address, it has no way to add any autodetection for it. The patch were tested by me and by Raimundo on his board. Thanks to those tests, several bugs related to em2800 support were corrected. for producing the usbsnoop dump, used to get the gpio's and allowing me to remotelly access his machine and to the needed tests. Thanks-to: Raimundo Eduvirgnes de Oliveira <eduvirgens@yahoo.com.br> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mauro Carvalho Chehab 提交于
Due to hardware limitation, em2800 chips can't work at resolutions higher than 640x576, since the URB packet size is not enough. The effect is that the image looses packages and shows a distortion along the vertical axes. Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mauro Carvalho Chehab 提交于
It seems that some patch broke alt modprobe parameter. Fix it to allow changing alternate interfaces during module load and at runtime. If changed during runtime, you'll need to stop a and restart stream for the parameter to be used. Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Jean Delvare 提交于
Recent fixes to the em28xx and saa7134 drivers have been overzealous. While the ir-kbd-i2c platform data indeed needs to be persistent, the struct i2c_board_info doesn't, as it is only used by i2c_new_device(). So revert a part of the original fixes, to save some memory. Signed-off-by: NJean Delvare <khali@linux-fr.org> Acked-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 19 9月, 2009 4 次提交
-
-
由 Antti Palosaari 提交于
Support for Reddo DVB-C USB TV Box device. Remote is not working yet. Thanks to Benjamin Larsson <banan@ludd.ltu.se> Cc: Benjamin Larsson <banan@ludd.ltu.se> Signed-off-by: NAntti Palosaari <crope@iki.fi> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Devin Heitmueller 提交于
The current locking infrastructure didn't support having multiple fds accessing the device (such as video and vbi). Rework the locking infrastructure, borrowing the design from cx88. This work was sponsored by EyeMagnet Limited. Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Devin Heitmueller 提交于
Add support for raw VBI capture for the em28xx bridge, currently only for NTSC. Support for PAL capture to follow shortly (including the removal of numerous hard-coded NTSC-specific sizes for capture buffers, etc). Note that the code currently changes the default current norm from PAL to NTSC (so that zvbi-ntsc-cc works properly). The default norm really should be moved into a board-level parameter. This work was sponsored by EyeMagnet Limited. Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Devin Heitmueller 提交于
Add code enabling the VBI registers for variants of the em28xx chip that support VBI, and make sure the isoc streaming code continues to work for the video component of the stream (note the video and vbi data arrive intermixed on the same isoc pipe). Note that this version just drops the actual VBI data onto the floor as opposed to processing it. The "#ifdef 0" tags are for the videobuf code that appears in the next patch in this series. We created a separate version of the isoc_copy version for parsing the version of the stream that includes VBI data. In theory, they might be able to be merged at some point in the future, but the initial goal is to ensure that we do not cause any regressions with devices that do not have VBI support. This work was sponsored by EyeMagnet Limited. Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 13 9月, 2009 1 次提交
-
-
由 Mauro Carvalho Chehab 提交于
Currently, the logic to load ir i2c ancillary module is broken. It is associated to Hauppauge devices with IR flag on their eeprom, no matter if the device uses i2c or em28xx direct IR support. That's wrong. Instead, add a flag to the boards that use i2c IR chips and load the module only for those devices and if ir is not disabled. Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 12 9月, 2009 3 次提交
-
-
由 Mauro Carvalho Chehab 提交于
ir-kbd-i2c's ir_probe() function can be called much later (i.e. at ir-kbd-i2c module load), than the lifetime of a struct IR_i2c_init_data allocated off of the stack in cx18_i2c_new_ir() at registration time. Make sure we pass a pointer to a persistent IR_i2c_init_data object at i2c registration time. Thanks to Brian Rogers, Dustin Mitchell, Andy Walls and Jean Delvare to rise this question. Before this patch, if ir-kbd-i2c were probed after em28xx, trash data were used. After the patch, no matter what order, it is properly reported as tested by me: input: i2c IR (i2c IR (EM2840 Hauppaug as /class/input/input10 ir-kbd-i2c: i2c IR (i2c IR (EM2840 Hauppaug detected at i2c-4/4-0030/ir0 [em28xx #0] Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mauro Carvalho Chehab 提交于
Currently, V4L uses a scancode table whose index is the scancode and the value is the keycode. While this works, it has some drawbacks: 1) It requires that the scancode to be at the range 00-7f; 2) keycodes should be masked on 7 bits in order for it to work; 3) due to the 7 bits approach, sometimes it is not possible to replace the default keyboard to another one with a different encoding rule; 4) it is different than what is done with dvb-usb approach; 5) it requires a typedef for it to work. This is not a recommended Linux CodingStyle. This patch is part of a larger series of IR changes. It basically replaces the IR_KEYTAB_TYPE tables by a structured table: struct ir_scancode { u16 scancode; u32 keycode; }; This is very close to what dvb does. So, a further integration with DVB code will be easy. While we've changed the tables, for now, the IR keycode handling is still based on the old approach. The only notable effect is the redution of about 35% of the ir-common module size: text data bss dec hex filename 6721 29208 4 35933 8c5d old/ir-common.ko 5756 18040 4 23800 5cf8 new/ir-common.ko In thesis, we could be using above u8 for scancode, reducing even more the size of the module, but defining it as u16 is more convenient, since, on dvb, each scancode has up to 16 bits, and we currently have a few troubles with rc5, as their scancodes are defined with more than 8 bits. This patch itself shouldn't be doing any functional changes. Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mauro Carvalho Chehab 提交于
[mchehab@redhat.com: Fix a few wrong IR keymaps] Signed-off-by: NShine Liu <shinel@foxmail.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 31 8月, 2009 1 次提交
-
-
由 Mauro Carvalho Chehab 提交于
[mchehab@redhat.com: fix merge conflict and a few CodingStyle issues] Signed-off-by: NSteve Gotthardt <gotthardt@gmail.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 14 8月, 2009 1 次提交
-
-
由 Mauro Carvalho Chehab 提交于
Due to historical reasons, em28xx driver gets two consecutive frames and fold them into an unique framing, doing interlacing. While this works fine for TV images, this produces two bad effects with webcams: 1) webcam images are progressive. Merging two consecutive images produce interlacing artifacts on the image; 2) since the driver needs to get two frames, it reduces the maximum frame rate by two. Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 25 7月, 2009 6 次提交
-
-
由 Mauro Carvalho Chehab 提交于
Thanks to Wally <wally@voosen.eu> for bringing the issue and helping with the tests. Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mauro Carvalho Chehab 提交于
Depending on the video input format, vinmode/vinctl needs adjustments. For TV, this is not relevant, since the supported decoders output data at the same format. However, webcam sensors may have different formats, so, this needs to be adjusted based on the device. Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mauro Carvalho Chehab 提交于
In order to properly estimate fps, mt9v011 sensor driver needs to know what is the used frequency on the sensor cristal. Adds the proper fields and initialization code for specifying the cristal frequency. Also, based on experimentation, it was noticed that the Silvercrest is outputing data at 7 fps. This means that it should be using a 6.3 MHz cristal. This information needs to be double checked later, by opening the device. Anyway, by using this value for xtal, at least now we have the correct fps report. Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mauro Carvalho Chehab 提交于
While trying to fix an mt9v001 webcam, I noticed that HSCALE/VSCALE do work with em28xx + webcam. The issue is that the scaling setup depends on the number of visible rows/cols of the input image. With mt9v011 (Silvercrest), the resolution is 640x480. So, the scaling is different from a normal TV image (720x480 on NTSC). This were causing a wrong scaling and a previous patch disabled scaling. As each sensor have their different resolution setting, the xres/yres should be adjusted accordingly with the input sensor. Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mauro Carvalho Chehab 提交于
Instead of using em28xx board decoder field for storing sensor information, let's use instead a separate field for it. Also, as sensors are currently autodetected, there's no need of having it at the boards description. So, move it to the main em28xx struct. Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mauro Carvalho Chehab 提交于
Just renames the flag, to use a clearer name. Later patches will use this flag to properly set some drivers behaviors for webcams. Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 06 7月, 2009 1 次提交
-
-
由 Mauro Carvalho Chehab 提交于
This webcam uses a em2710 chipset, that identifies itself as em2820, plus a mt9v011 sensor, and a DY-301P lens. It needs a few different initializations than a normal em28xx device. Thanks to Hans de Goede <hdegoede@redhat.com> and Douglas Landgraf <dougsland@redhat.com> for providing the acces for the webcam during this weekend, I could make a patch for it while returning back from FISL/Fudcom LATAM 2009. Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 23 6月, 2009 1 次提交
-
-
由 Devin Heitmueller 提交于
Add support for the EVGA inDtube. Both ATSC and analog side validated as fully functional. Thanks to Jake Crimmins from EVGA for providing the correct GPIO info. Thanks to Alan Hagge for doing all the device testing. Thanks to Greg Williamson for providing hardware for testing. Cc: Jake Crimmins <jcrimmins@evga.com> Cc: Alan Hagge <ahagge@gmail.com> Cc: Greg Williamson <cheeseboy16@gmail.com> Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 17 6月, 2009 8 次提交
-
-
由 Franklin Meng 提交于
Added an entry for Kworld 315 (for while, dvb only) Signed-off-by: NFranklin Meng <fmeng2002@yahoo.com> Signed-off-by: NDouglas Schilling Landgraf <dougsland@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Devin Heitmueller 提交于
Make the KWorld 2800d work properly. In this case, that means making the profile more generic so that it works for both the Pointnix Intra-Oral USB camera and the KWorld device. The device provides the audio through a pass-thru cable, so we don't need an actual audio capture profile (neither the K-World device nor the Pointnix have an onboard audio decoder). Thanks to Paul Thomas for providing sample hardware. Cc: Paul Thomas <pthomas8589@gmail.com> Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Jean Delvare 提交于
For specific boards, pass initialization data to ir-kbd-i2c instead of modifying the settings after the device is initialized. This is more efficient and easier to read. Signed-off-by: NJean Delvare <khali@linux-fr.org> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Jean Delvare 提交于
Let card drivers probe for IR receiver devices and instantiate them if found. Ultimately it would be better if we could stop probing completely, but I suspect this won't be possible for all card types. There's certainly room for cleanups. For example, some drivers are sharing I2C adapter IDs, so they also had to share the list of I2C addresses being probed for an IR receiver. Now that each driver explicitly says which addresses should be probed, maybe some addresses can be dropped from some drivers. Also, the special cases in saa7134-i2c should probably be handled on a per-board basis. This would be more efficient and less risky than always probing extra addresses on all boards. I'll give it a try later. Signed-off-by: NJean Delvare <khali@linux-fr.org> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mauro Carvalho Chehab 提交于
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mauro Carvalho Chehab 提交于
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Devin Heitmueller 提交于
The em28xx actually has a register that tells the driver what the maximum packet size is (based on a value programmed into the eeprom). Make use of that register instead of assuming a hardcoded value of 564 (since 564 is not correct for devices that do QAM such as the KWorld 340u). Note that for now the em2874 code isn't there, falling back to the 564 value, however this is not a problem since there are not any em2874 based devices in the current v4l-dvb tree). Thanks to Jarod Wilson for detecting the initial problem and figuring out that the isoc configuration was wrong for his device. Cc: Jarod Wilson <jarod@wilsonet.com> Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
Added EmpireTV entry. Thanks to Xwang <xwang1976@email.it> to provide data for this board. Signed-off-by: NDouglas Schilling Landgraf <dougsland@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 07 4月, 2009 1 次提交
-
-
Converted em28xx driver to v4l2_subdev. Thanks to Hans Verkuil <hverkuil@xs4all.nl> for helping this conversion. Signed-off-by: NDouglas Schilling Landgraf <dougsland@redhat.com> Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 30 3月, 2009 9 次提交
-
-
由 Vitaly Wool 提交于
Compro VideoMate uses an external audio DSP chip, controlled via tvaudio module (tda9874a). This patch improves em28xx infrastructure to support an external audio processor and fixes the Compro VideoMate entry to work with it. Signed-off-by: NVitaly Wool <vital@embeddedalley.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
Removed EM2821_BOARD_PROLINK_PLAYTV_USB2 entry. This entry has a incorrect tuner set. Signed-off-by: NDouglas Schilling Landgraf <dougsland@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mauro Carvalho Chehab 提交于
As reported by Vitaly Wool <vital@embeddedalley.com>: > about half a year ago I posted the patch that basically enabled Compro > VideoMate For You USB TV box support. > The main problem is I couldn't get the sound working. > So I kind of decomposed the box and found out the audio decoder chip > used there was Philips TDA9874A. As far as I can see, it's not supported > within the em28xx suite although it is for other TV tuner drivers. A tvaudio modprobing confirms that tda9874a chip is accessible via i2c: tvaudio: TV audio decoder + audio/video mux driver tvaudio: known chips: tda9840, tda9873h, tda9874h/a, tda9850, tda9855, tea6300, tea6320, tea6420, tda8425, pic16c54 (PV951), ta8874z tvaudio' 1-0058: chip found @ 0xb0 tvaudio' 1-0058: tvaudio': chip_read2: reg254=0x11 tvaudio' 1-0058: tvaudio': chip_read2: reg255=0x2 tvaudio' 1-0058: tda9874a_checkit(): DIC=0x11, SIC=0x2. tvaudio' 1-0058: found tda9874a. tvaudio' 1-0058: tda9874h/a found @ 0xb0 (em28xx #0) tvaudio' 1-0058: tda9874h/a: chip_write: reg0=0x0 tvaudio' 1-0058: tda9874h/a: chip_write: reg1=0xc0 tvaudio' 1-0058: tda9874h/a: chip_write: reg2=0x2 tvaudio' 1-0058: tda9874h/a: chip_write: reg11=0x80 tvaudio' 1-0058: tda9874h/a: chip_write: reg12=0x0 tvaudio' 1-0058: tda9874h/a: chip_write: reg13=0x0 tvaudio' 1-0058: tda9874h/a: chip_write: reg14=0x1 tvaudio' 1-0058: tda9874h/a: chip_write: reg15=0x0 tvaudio' 1-0058: tda9874h/a: chip_write: reg16=0x14 tvaudio' 1-0058: tda9874h/a: chip_write: reg17=0x50 tvaudio' 1-0058: tda9874h/a: chip_write: reg18=0xf9 tvaudio' 1-0058: tda9874h/a: chip_write: reg19=0x80 tvaudio' 1-0058: tda9874h/a: chip_write: reg20=0x80 tvaudio' 1-0058: tda9874h/a: chip_write: reg24=0x80 tvaudio' 1-0058: tda9874h/a: chip_write: reg255=0x0 tvaudio' 1-0058: tda9874a_setup(): A2, B/G [0x00]. tvaudio' 1-0058: tda9874h/a: thread started] This patch automatically loads tvaudio when needed (currently, only with this board). Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Indika Katugampala 提交于
[dougsland@redhat.com: Fixed CodingStyle] Signed-off-by: NIndika Katugampala <indika_20012001@yahoo.co.jp> Signed-off-by: NDouglas Schilling Landgraf <dougsland@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Nicola Soranzo 提交于
Lots of coding style fixes and a typo correction for em28xx. [dougsland@redhat.com: fixed a reject due to a change on em28xx-audio.c] Signed-off-by: NNicola Soranzo <nsoranzo@tiscali.it> Signed-off-by: NDouglas Schilling Landgraf <dougsland@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
Added macros EM28XX_START_AUDIO and EM28XX_STOP_AUDIO for em28xx_cmd(). Signed-off-by: NDouglas Schilling Landgraf <dougsland@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Robert Krakora 提交于
Essentially if a snd_em28xx_capture_trigger() stop followed by a snd_em28xx_capture_trigger() start would not yield any data because there was some logic put in with an adev->shutdown variable which did not seem warranted in my humble opinion. It would cause snd_em28xx_capture_trigger start never to start up the audio stream until the device was closed and reopened again. Upon re-opening the device adev->shutdown is reset and audio data would again flow. Signed-off-by: NRobert Krakora <rob.krakora@messagenetsystems.com> Signed-off-by: NDouglas Schilling Landgraf <dougsland@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mauro Carvalho Chehab 提交于
Thanks to Peter Senna Tschudin <peter.senna@gmail.com> for borrow me one of those devices. Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mauro Carvalho Chehab 提交于
Thanks to Peter Senna Tschudin <peter.senna@gmail.com> for borrow me one of those devices. Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-