Re: Support on discontinuous planer buffer and stride
On Friday 09 October 2009 07:07:32 Jun Nie wrote:
2009/9/23 Jun Nie niej0...@gmail.com:
Hi,
I re-send this email for the last one is rejected by system. I am
sorry if you guys received both.
I am optimizing video playback with overlay with V4L2 driver. The
video content is a sub-region of codec output. Thus a memory copy is
necessary.
Is there plan to support for stride and discrete YUV planer in
kernel? Such as below changes can help much for my usage case.
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -529,7 +529,20 @@ struct v4l2_buffer {
__u32 offset;
unsigned long userptr;
} m;
+ /* UV/GB location is valid only in planer case */
+ union {
+ __u32 offset_ug;
+ unsigned long userptr_ug;
+ } m_ug;
+ union {
+ __u32 offset_vb;
+ unsigned long userptr_vb;
+ } m_vb;
__u32 length;
+ /* stride of YUV or RGB */
+ __u32 stride_yr;
+ __u32 stride_ug;
+ __u32 stride_vb;
__u32 input;
__u32 reserved;
};
If such change is acceptable for everyone, I may help on the
implementation.
Any comments are welcome.
Jun
Hi, Hans/Guennadi
What do you think of supporting this feature?
Jun
Well, it is definitely not possible to do it in this manner since changing
the size of struct v4l2_buffer will break the API. Furthermore, something like
this will only work if the DMA engine can handle strides. Is that the case
for your hardware? I don't think you mentioned what the hardware is you use.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
Re: [Linux-uvc-devel] [PATCH] Re: uvcvideo: Finally fix Logitech Quickcam for Notebooks Pro
On Friday 09 October 2009, Laurent Pinchart wrote: Hi Ondrej, On Wednesday 07 October 2009 14:59:40 Ondrej Zary wrote: On Tuesday 06 October 2009, Ondrej Zary wrote: Hello, I have a Logitech Quickcam for Notebooks Pro camera (046d:08c3) which just does not work even with kernel 2.6.31 and has never worked well before. On http://linux-uvc.berlios.de/, there are two problems listed. I want to really fix these two problems so the camera will just work after plugging in (and not disconnect). I started with problem no. 2 as this causes the camera not to work at all when plugged in: usb 5-2.4: new high speed USB device using ehci_hcd and address 7 usb 5-2.4: configuration #1 chosen from 1 choice uvcvideo: Found UVC 1.00 device unnamed (046d:08c3) uvcvideo: UVC non compliance - GET_DEF(PROBE) not supported. Enabling workaround. uvcvideo: Failed to query (129) UVC probe control : -110 (exp. 26). uvcvideo: Failed to initialize the device (-5). When I do modprobe snd_usb_audio, then rmmod snd_usb_audio and finally modprobe uvcvideo, it works. So it looks like snd_usb_audio does some initialization that allows uvcvideo to work. It didn't work at all I didn't have snd_usb_audio module compiled. What was the change that supposedly broke this in 2.6.22? I discovered that it's not related to usb audio at all. Doing rmmod uvcvideo and modprobe uvcvideo repeatedly succeeded after a couple of tries. Increasing UVC_CTRL_STREAMING_TIMEOUT to 3000 helped (2000 was not enough). Increase UVC_CTRL_STREAMING_TIMEOUT to fix initialization of Logitech Quickcam for Notebooks Pro. This fixes following error messages: uvcvideo: UVC non compliance - GET_DEF(PROBE) not supported. Enabling workaround. uvcvideo: Failed to query (129) UVC probe control : -110 (exp. 26). uvcvideo: Failed to initialize the device (-5). Signed-off-by: Ondrej Zary li...@rainbow-software.org --- linux-2.6.31-orig/drivers/media/video/uvc/uvcvideo.h2009-09-10 00:13:59.0 +0200 +++ linux-2.6.31/drivers/media/video/uvc/uvcvideo.h2009-10-07 13:47:27.0 +0200 @@ -304,7 +304,7 @@ #define UVC_MAX_STATUS_SIZE16 #define UVC_CTRL_CONTROL_TIMEOUT 300 -#define UVC_CTRL_STREAMING_TIMEOUT 1000 +#define UVC_CTRL_STREAMING_TIMEOUT 3000 /* Devices quirks */ #define UVC_QUIRK_STATUS_INTERVAL 0x0001 Thanks for the patch. I wonder if it will help other Logitech users. The UVC specification unfortunately doesn't give a time boundary for answering streaming requests, so that's up to the developers. I'm pretty sure we will find at least one webcam model that will require 3001ms at some point :-) I was thinking about adding a module parameter to set the streaming control timeout. I'm not sure what the default value should be though. What's your opinion on this ? If we decide to increase the default value, where should we stop ? I really don't know. Maybe only the first request is slow as the hardware needs some time to initialize? If someone knows what value is used by Windows or Mac OS X, that's probably the right choice as most devices are tested with them. -- Ondrej Zary -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
PULL request: http://linuxtv.org/hg/~hgoede/gspca
Hi Mauro, Please pull from: http://linuxtv.org/hg/~hgoede/gspca For the following changes: -Improved detection of the sensor type for mr97310a cams -Gain, exposure and brightness controls for mr97310a VGA cams with sensor type 1 -Cleanups of the work queue functions for the jeilinj, sq905 and sq905c drivers. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppage WinTV-HVR-900H
Devin Heitmueller wrote: On Thu, Oct 8, 2009 at 2:20 PM, Ali Abdallah al...@xfce.org wrote: I have the card since alsmost 3 years, it never worked, but now i'm in urgent need of getting an analog usb stick to work with Linux. The PCTV hybrid: Bus 001 Device 004: ID eb1a:2881 eMPIA Technology, Inc. Thanks for you support, but i need an analog usb stick, well hopefully the wintv 900H will get supported soon. Well, I added support for that device last month, so I would suggest you install the latest v4l-dvb code from http://linuxtv.org/hg/v4l-dvb. Directions can be found here: http://linuxtv.org/repo Okay, i installed the latest drivers+the firmware of the device using extract_xc3028.pl, the device seems to be detected now, i can detect all the analog TV of my cable using tvtime, but manually, i mean i had to disable signal detection when scanning, otherwise i got no results, since the picture quality is terrible. Of course i'm sure that all the connections (cable to antenna, cable to the usb stick, ...) are correct, since it works with my old PC equipped with a PCI TV card. Any advice, what could be the problem? firmware? since you said (you added support for this device) should i open a bug report? is this device reported as working by other users? Please help if possible, almost two weeks with no real success. Cheers, Devin Cheers, Ali. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppage WinTV-HVR-900H
Markus Rechberger wrote: Aside of that we also fully support Linux http://support.sundtek.de/index.php/topic,4.0.html http://support.sundtek.de/index.php/topic,7.0.html We also use to report bugs to Distributors in order to improve general Multimedia Support. Customers also get dedicated support as far as needed in order to get everything work properly (if needed). Best Regards, Markus binary driver for very expensive and unavailable hardware -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppage WinTV-HVR-900H
On Fri, Oct 9, 2009 at 9:59 AM, Simon Kenyon si...@koala.ie wrote: Markus Rechberger wrote: Aside of that we also fully support Linux http://support.sundtek.de/index.php/topic,4.0.html http://support.sundtek.de/index.php/topic,7.0.html We also use to report bugs to Distributors in order to improve general Multimedia Support. Customers also get dedicated support as far as needed in order to get everything work properly (if needed). Best Regards, Markus binary driver for very expensive and unavailable hardware Available from 20th Oct on so in 11 days. There are not many competitive devices (none) available for linux which deliver such support. On the other side it's not kernel based either, it's entirely in userspace. It's also entirely supported by all participating companies. The driver is using the same components as the Windows driver. There's no way to crash the kernel with that driver, and it works from 2.6.15 kernelseries on without having to fiddle around. In any case it's up to the customer if he wants an easy installation or a complicated one, similar devices for Mac are available at a higher price. Even though when drivers are officially in the kernel still not all distributions are shipping all the kernel drivers especially the firmware isn't shipped with most distributions either. We do have customers who are not comfortable with having to compile kernelmodules and just want to have it work. Another positive side effect every system can use the same driver, updates are easily possible for everyone (unlike kernel drivers for such devices which have to be recompiled for every system). The installation of it usually takes below 10 seconds on any system we tested (Ubuntu, Redhat, Suse, Sidux, Gentoo, Acer One Netbook, Arch Linux) Best Regards, Markus -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
libv4l release: 0.6.2: the 3th upside down release
Hi All, I'm very happy to announce the release of libv4l-0.6.2 The main changes this release is 17 new laptops in the list of laptops whose camera modules (mostly uvc) are known to be mounted upside down in the frame and it will automatically correct the image for this. (This upside down business is becoming a never ending story) libv4l-0.6.2 - * Add more laptop models to the upside down devices table * Put usb id in controls shm segment name for USB devices, to better distuingish between devices plugged into the same port * Enable software whitebalance and autogain for mr97310a cameras * Improvements / tweaks to software autogain algorithm Note new URL! Get it here: http://people.fedoraproject.org/~jwrdegoede/libv4l-0.6.2.tar.gz Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] soc-camera: tw9910: Revision 0 and 1 are able to use
Signed-off-by: Kuninori Morimoto morimoto.kunin...@renesas.com
---
drivers/media/video/tw9910.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/tw9910.c b/drivers/media/video/tw9910.c
index 269ab04..7bf90a2 100644
--- a/drivers/media/video/tw9910.c
+++ b/drivers/media/video/tw9910.c
@@ -883,11 +883,12 @@ static int tw9910_video_probe(struct soc_camera_device
*icd,
/*
* check and show Product ID
+* So far only revisions 0 and 1 have been seen
*/
val = i2c_smbus_read_byte_data(client, ID);
if (0x0B != GET_ID(val) ||
- 0x00 != GET_ReV(val)) {
+ 0x01 GET_ReV(val)) {
dev_err(client-dev,
Product ID error %x:%x\n, GET_ID(val), GET_ReV(val));
return -ENODEV;
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PULL] http://udev.netup.ru/hg/v4l-dvb-aospan
Hi Abylai, Wouldn't be be better to just use dvbtraffic userspace apps for it? Also, your patch has some coding style issues. Em Thu, 24 Sep 2009 18:41:08 +0400 Abylai Ospan aos...@netup.ru escreveu: Mauro, Please pulll changes from: http://udev.netup.ru/hg/v4l-dvb-aospan/rev/711d9630876f Show speed of transport stream in Kbit/sec: for example, data obtained from DVB-S2 transponder from Eutelsat W4: Jun 27 12:06:01 udev TS speed 58608 Kbits/sec Jun 27 12:06:03 udev TS speed 58422 Kbits/sec Jun 27 12:06:04 udev TS speed 58608 Kbits/sec for DVB-S1 transponder from the same satellite: Jun 27 12:07:00 udev TS speed 37108 Kbits/sec Jun 27 12:07:02 udev TS speed 37089 Kbits/sec Jun 27 12:07:04 udev TS speed 37202 Kbits/sec this feature can be enabled using following command: echo 1 /sys/module/dvb_core/parameters/dvb_demux_speedcheck and disabled by following command: echo 0 /sys/module/dvb_core/parameters/dvb_demux_speedcheck Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppage WinTV-HVR-900H
On Fri, Oct 9, 2009 at 5:34 AM, Ali Abdallah al...@xfce.org wrote: Okay, i installed the latest drivers+the firmware of the device using extract_xc3028.pl, the device seems to be detected now, i can detect all the analog TV of my cable using tvtime, but manually, i mean i had to disable signal detection when scanning, otherwise i got no results, since the picture quality is terrible. Of course i'm sure that all the connections (cable to antenna, cable to the usb stick, ...) are correct, since it works with my old PC equipped with a PCI TV card. Any advice, what could be the problem? firmware? since you said (you added support for this device) should i open a bug report? is this device reported as working by other users? Please help if possible, almost two weeks with no real success. Could you please provide a screen shot of the tvtime output? Also, are you trying to capture over-the-air or are you capturing cable television? What analog standard are you using? PAL-BG? Did you make sure to tell tvtime which analog standard you are using? Could you try the S-Video or composite input and see if the picture quality is still bad (as this well help isolate whether it's a problem with the tuner chip or the decoder. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppage WinTV-HVR-900H
Devin Heitmueller wrote: On Fri, Oct 9, 2009 at 5:34 AM, Ali Abdallah al...@xfce.org wrote: Okay, i installed the latest drivers+the firmware of the device using extract_xc3028.pl, the device seems to be detected now, i can detect all the analog TV of my cable using tvtime, but manually, i mean i had to disable signal detection when scanning, otherwise i got no results, since the picture quality is terrible. Of course i'm sure that all the connections (cable to antenna, cable to the usb stick, ...) are correct, since it works with my old PC equipped with a PCI TV card. Any advice, what could be the problem? firmware? since you said (you added support for this device) should i open a bug report? is this device reported as working by other users? Please help if possible, almost two weeks with no real success. Could you please provide a screen shot of the tvtime output? I will provide you a screenshot when i go back home this evening. Also, are you trying to capture over-the-air or are you capturing cable television? It is a cable but at the end it is connected to main antenna of the building. What analog standard are you using? PAL-BG? SECAM. Did you make sure to tell tvtime which analog standard you are using? Yes i'm sure, settings are SECAM, area France. Could you try the S-Video or composite input and see if the picture quality is still bad (as this well help isolate whether it's a problem with the tuner chip or the decoder. I will also try these at reply this evening. Devin Cheers, Ali. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RFC (v1.1): V4L - Support for video timings at the input/output interface
Hello,
Here is the version 1.1 of the RFC which will be used for implementing
the video timing APIs in the V4L2 core. Please review and let me know
if I have missed something. Following are the changes incorporated in this
version :-
1) Added width and height parameters in the struct v4l2_dv_enum_presets
2) Corrected duplicate values in the defined preset values
3) Added following capability to indicate if the driver supports setting
standards through existing S_STD IOCTL.
#define V4L2_SUPPORTS_STD0x0004
4) Removed negative Polarity masks
5) Added issue #7 for camera sensor frame size/frame rate setting.
RFC (v1.1): V4L - Support for video timings at the input/output interface
Version : 1.1
Background
---
Currently v4l2 specification supports capturing video frames from TV signals
using tuners (input type V4L2_INPUT_TYPE_TUNER) and baseband TV signals
(V4L2_INPUT_TYPE_CAMERA) and sensors. Similarly on the output side, the signals
could be TV signal (V4L2_OUTPUT_TYPE_MODULATOR), baseband TV signal
(V4L2_OUTPUT_TYPE_ANALOG) or hybrid analog VGA overlay
(V4L2_OUTPUT_TYPE_ANALOGVGAOVERLAY) which output from a graphics card and
then use chromakeying to replace part of the picture with the video.
V4L2_OUTPUT_TYPE_ANALOG V4L2_INPUT_TYPE_CAMERA are for analog interfaces that
includes composite, S-Video and VGA (for output only). Note that even though
VGA is a supported output, we don't have anyway to set the standard or timing
on the output. Standard ids are only defined for TVs using
v4l2_std_id and a set of bit masks defined for analog TV standards.
Today we have a wide variety of different interfaces available to
transmit/receive video or graphics content between source device and
destination device. Following are some of the interfaces used in addition to
the ones described in the v4l2 specification.
Component analog input/output interface - ED/HD video
DVI - Digital only, ANALOG only, DVI integrated that support Digital and
Analog;
Dual Link - Where second data link is used for higher bandwidth
SDI - Serial digital interface standardized by SMPTE
HDMI - HD video and Audio
DisplayPort - digital audio/video interconnect by VESA
V4L2 specification currently defined NTSC/PAL/SECAM (all variants) standards
for describing the timing of the signal transmitted over these interfaces. Even
though the specification defined ANALOG output type for VGA, there are no ways
to set the timings used for output to VGA or LCD display monitors. Some of the
proprietary implementations used existing standards IOCTL, VIDIOC_S_STD, to set
these timings over these interfaces. For example, TI SoCs have Video Processing
Back End (VPBE) on various media SOCs (Eg, DM6446, DM355 etc) that can output
signal for Analog TV and VGA interfaces (using Digital LCD port) and support
timings for displaying SD and HD videos (1080i, 1080p and 720p) as well as over
VGA interface to a CRT or LCD display monitor. So we need to enhance the v4l2
specification to allow applications to set these timings in the capture or
output devices. This RFC proposes to add new IOCTLs for setting/getting timings
over the different interfaces described above and freeze the the use of
existing standards IOCTL and standards IDs for analog TVs only.
Timings
---
The timings at the analog or digital interface that are not covered by the
v4l2_std_id can be defined using a set of preset values that are used by the
hardware where the timings are predefined or by a set of timing values which
can be configured at the hardware to generate the signal expected at the
interface. The former will be used for hardware like TVP7002/THS8200 which
specifies preset timing required for output HD video such 1080i50/60, 720p50/60
etc. The latter can be used for hardware that requires configuration of frame
timing such as front porch, hsync length, vsync length, pixel clock etc. For
example the earlier mentioned TI SOCs have a Digital LCD port that can be
configured to output different timing values expected by LCD Display monitors.
Preset timings (defined by VESA, SMPTE or BT.656/BT.1120 or others) can be
defined by the following structure:-
struct v4l2_dv_preset {
__u32preset;
__u32reserved[4];
};
Where preset is one of the following values:-
#define V4L2_DV_CUSTOM 0x
#define V4L2_DV_480I59_94 0x0001
#define V4L2_DV_480I60 0x0002
#define V4L2_DV_480P23_976 0x0003
#define V4L2_DV_480P24 0x0004
#define V4L2_DV_480P29_97 0x0005
#define V4L2_DV_480P30 0x0006
#define V4L2_DV_576I50 0x0007
#define V4L2_DV_576P25 0x0008
#define V4L2_DV_576P50 0x0009
#define V4L2_DV_720P23_976 0x000A
#define V4L2_DV_720P24
Re: RFC (v1.1): V4L - Support for video timings at the input/output interface
Hi Murali, Reading through this I noticed that there was one thing that is probably no longer needed: now that we have the SUPPORTS_CUSTOM_TIMING capability there is no need to include the CUSTOM preset when enumerating presets. Instead I suggest that the INVALID preset define takes the place of the CUSTOM preset. Also, these capabilities should probably be renamed to V4L2_IN_CAP_STD/PRESETS/CUSTOM. This is more in line with the current naming convention. Otherwise I think this is pretty good. One thing: did you check against the FB API? We should have at least the same timing parameters as they have (it is my understanding that timings can also be setup through the FB API). Regards, Hans Hello, Here is the version 1.1 of the RFC which will be used for implementing the video timing APIs in the V4L2 core. Please review and let me know if I have missed something. Following are the changes incorporated in this version :- 1) Added width and height parameters in the struct v4l2_dv_enum_presets 2) Corrected duplicate values in the defined preset values 3) Added following capability to indicate if the driver supports setting standards through existing S_STD IOCTL. #define V4L2_SUPPORTS_STD0x0004 4) Removed negative Polarity masks 5) Added issue #7 for camera sensor frame size/frame rate setting. RFC (v1.1): V4L - Support for video timings at the input/output interface Version : 1.1 Background --- Currently v4l2 specification supports capturing video frames from TV signals using tuners (input type V4L2_INPUT_TYPE_TUNER) and baseband TV signals (V4L2_INPUT_TYPE_CAMERA) and sensors. Similarly on the output side, the signals could be TV signal (V4L2_OUTPUT_TYPE_MODULATOR), baseband TV signal (V4L2_OUTPUT_TYPE_ANALOG) or hybrid analog VGA overlay (V4L2_OUTPUT_TYPE_ANALOGVGAOVERLAY) which output from a graphics card and then use chromakeying to replace part of the picture with the video. V4L2_OUTPUT_TYPE_ANALOG V4L2_INPUT_TYPE_CAMERA are for analog interfaces that includes composite, S-Video and VGA (for output only). Note that even though VGA is a supported output, we don't have anyway to set the standard or timing on the output. Standard ids are only defined for TVs using v4l2_std_id and a set of bit masks defined for analog TV standards. Today we have a wide variety of different interfaces available to transmit/receive video or graphics content between source device and destination device. Following are some of the interfaces used in addition to the ones described in the v4l2 specification. Component analog input/output interface - ED/HD video DVI - Digital only, ANALOG only, DVI integrated that support Digital and Analog; Dual Link - Where second data link is used for higher bandwidth SDI - Serial digital interface standardized by SMPTE HDMI - HD video and Audio DisplayPort - digital audio/video interconnect by VESA V4L2 specification currently defined NTSC/PAL/SECAM (all variants) standards for describing the timing of the signal transmitted over these interfaces. Even though the specification defined ANALOG output type for VGA, there are no ways to set the timings used for output to VGA or LCD display monitors. Some of the proprietary implementations used existing standards IOCTL, VIDIOC_S_STD, to set these timings over these interfaces. For example, TI SoCs have Video Processing Back End (VPBE) on various media SOCs (Eg, DM6446, DM355 etc) that can output signal for Analog TV and VGA interfaces (using Digital LCD port) and support timings for displaying SD and HD videos (1080i, 1080p and 720p) as well as over VGA interface to a CRT or LCD display monitor. So we need to enhance the v4l2 specification to allow applications to set these timings in the capture or output devices. This RFC proposes to add new IOCTLs for setting/getting timings over the different interfaces described above and freeze the the use of existing standards IOCTL and standards IDs for analog TVs only. Timings --- The timings at the analog or digital interface that are not covered by the v4l2_std_id can be defined using a set of preset values that are used by the hardware where the timings are predefined or by a set of timing values which can be configured at the hardware to generate the signal expected at the interface. The former will be used for hardware like TVP7002/THS8200 which specifies preset timing required for output HD video such 1080i50/60, 720p50/60 etc. The latter can be used for hardware that requires configuration of frame timing such as front porch, hsync length, vsync length, pixel clock etc. For example the earlier mentioned TI SOCs have a Digital LCD port that can be configured to output different timing values expected by LCD Display monitors. Preset timings (defined by VESA, SMPTE or
Re: [PATCH] media/video: adding __init/__exit macros to various drivers
On Tue, 29 Sep 2009, Peter Huewe wrote: From: Peter Huewe peterhu...@gmx.de Trivial patch which adds the __init/__exit macros to the module_init/ module_exit functions of the following drivers in media video: drivers/media/video/ivtv/ivtv-driver.c drivers/media/video/cx18/cx18-driver.c drivers/media/video/davinci/dm355_ccdc.c drivers/media/video/davinci/dm644x_ccdc.c drivers/media/video/saa7164/saa7164-core.c drivers/media/video/saa7134/saa7134-core.c drivers/media/video/cx23885/cx23885-core.c This doesn't seem to be present in linux-next as of today. I have queued in in trivial tree. -- Jiri Kosina SUSE Labs, Novell Inc. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppage WinTV-HVR-900H
Devin Heitmueller wrote: On Fri, Oct 9, 2009 at 5:34 AM, Ali Abdallah al...@xfce.org wrote: Okay, i installed the latest drivers+the firmware of the device using extract_xc3028.pl, the device seems to be detected now, i can detect all the analog TV of my cable using tvtime, but manually, i mean i had to disable signal detection when scanning, otherwise i got no results, since the picture quality is terrible. Of course i'm sure that all the connections (cable to antenna, cable to the usb stick, ...) are correct, since it works with my old PC equipped with a PCI TV card. Any advice, what could be the problem? firmware? since you said (you added support for this device) should i open a bug report? is this device reported as working by other users? Please help if possible, almost two weeks with no real success. Could you please provide a screen shot of the tvtime output? Screenshots here for TV and S-Video input configuration with TV time. http://ali.blogsite.org/files/tvtime/ Could you try the S-Video or composite input and see if the picture quality is still bad (as this well help isolate whether it's a problem with the tuner chip or the decoder. Same picture quality with S-Video, but with composite there is no picture. Many thanks. Devin Cheers, Ali. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppage WinTV-HVR-900H
On Fri, Oct 9, 2009 at 1:22 PM, Ali Abdallah al...@xfce.org wrote: Screenshots here for TV and S-Video input configuration with TV time. http://ali.blogsite.org/files/tvtime/ Could you try the S-Video or composite input and see if the picture quality is still bad (as this well help isolate whether it's a problem with the tuner chip or the decoder. Same picture quality with S-Video, but with composite there is no picture. Ok, this helps alot. This rules out the tuner and suggests that perhaps the video decoder is not being programmed properly. Could you please send me the output of dmesg? I'll see about setting up a tree with some additional debugging for you to try out. Thanks, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppage WinTV-HVR-900H
Devin Heitmueller wrote: On Fri, Oct 9, 2009 at 1:22 PM, Ali Abdallah al...@xfce.org wrote: Screenshots here for TV and S-Video input configuration with TV time. http://ali.blogsite.org/files/tvtime/ Could you try the S-Video or composite input and see if the picture quality is still bad (as this well help isolate whether it's a problem with the tuner chip or the decoder. Same picture quality with S-Video, but with composite there is no picture. Ok, this helps alot. This rules out the tuner and suggests that perhaps the video decoder is not being programmed properly. Could you please send me the output of dmesg? usb 1-1: new high speed USB device using ehci_hcd and address 15 usb 1-1: configuration #1 chosen from 1 choice em28xx: New device USB 2881 Video @ 480 Mbps (eb1a:2881, interface 0, class 0) em28xx #0: chip ID is em2882/em2883 em28xx #0: i2c eeprom 00: 1a eb 67 95 1a eb 81 28 58 12 5c 00 6a 20 6a 00 em28xx #0: i2c eeprom 10: 00 00 04 57 64 57 00 00 60 f4 00 00 02 02 00 00 em28xx #0: i2c eeprom 20: 56 00 01 00 00 00 02 00 b8 00 00 00 5b 1e 00 00 em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 10 02 00 00 00 00 00 00 em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 20 03 55 00 53 00 em28xx #0: i2c eeprom 70: 42 00 20 00 32 00 38 00 38 00 31 00 20 00 56 00 em28xx #0: i2c eeprom 80: 69 00 64 00 65 00 6f 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom e0: 5a 00 55 aa 79 55 54 03 00 17 98 01 00 00 00 00 em28xx #0: i2c eeprom f0: 0c 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0xb8846b20 em28xx #0: EEPROM info: em28xx #0:AC97 audio (5 sample rates) em28xx #0:USB Remote wakeup capable em28xx #0:500mA max power em28xx #0:Table at 0x04, strings=0x206a, 0x006a, 0x em28xx #0: Identified as Unknown EM2750/28xx video grabber (card=1) em28xx #0: Your board has no unique USB ID. em28xx #0: A hint were successfully done, based on eeprom hash. em28xx #0: This method is not 100% failproof. em28xx #0: If the board were missdetected, please email this log to: em28xx #0: V4L Mailing List linux-media@vger.kernel.org em28xx #0: Board detected as Pinnacle Hybrid Pro tvp5150 1-005c: chip found @ 0xb8 (em28xx #0) tuner 1-0061: chip found @ 0xc2 (em28xx #0) xc2028 1-0061: creating new instance xc2028 1-0061: type set to XCeive xc2028/xc3028 tuner usb 1-1: firmware: requesting xc3028-v27.fw xc2028 1-0061: Loading 80 firmware images from xc3028-v27.fw, type: xc2028 firmware, ver 2.7 xc2028 1-0061: Loading firmware for type=BASE (1), id . xc2028 1-0061: Loading firmware for type=(0), id b700. SCODE (2000), id b700: xc2028 1-0061: Loading SCODE for type=MONO SCODE HAS_IF_4320 (60008000), id 8000. em28xx #0: Config register raw data: 0x58 em28xx #0: AC97 vendor ID = 0x em28xx #0: AC97 features = 0x6a90 em28xx #0: Empia 202 AC97 audio processor detected tvp5150 1-005c: tvp5150am1 detected. em28xx #0: v4l2 driver version 0.1.2 em28xx #0: V4L2 video device registered as /dev/video0 em28xx #0: V4L2 VBI device registered as /dev/vbi0 xc2028 1-0061: attaching existing instance xc2028 1-0061: type set to XCeive xc2028/xc3028 tuner em28xx #0/2: xc3028 attached DVB: registering new adapter (em28xx #0) DVB: registering adapter 0 frontend 0 (Zarlink ZL10353 DVB-T)... Successfully loaded em28xx-dvb tvp5150 1-005c: tvp5150am1 detected. tvp5150 1-005c: tvp5150am1 detected. tvp5150 1-005c: tvp5150am1 detected. xc2028 1-0061: Loading firmware for type=BASE F8MHZ (3), id . (0), id 00ff: xc2028 1-0061: Loading firmware for type=(0), id 0020. xc2028 1-0061: Loading SCODE for type=MONO SCODE HAS_IF_6320 (60008000), id 0020. tvp5150 1-005c: tvp5150am1 detected. xc2028 1-0061: Loading firmware for type=BASE F8MHZ (3), id . (0), id 00ff: xc2028 1-0061: Loading firmware for type=(0), id 0020. xc2028 1-0061: Loading SCODE for type=MONO SCODE HAS_IF_6320 (60008000), id 0020. I'll see about setting up a tree with some additional debugging for you to try out. Okay i'm ready to try it out. Thanks, Devin Cheers, Ali. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Fri Oct 9 19:00:03 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13083:89b7e6d5854a gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29.1-armv5: OK linux-2.6.30-armv5: OK linux-2.6.31-armv5: OK linux-2.6.32-rc3-armv5: ERRORS linux-2.6.32-rc3-armv5-davinci: ERRORS linux-2.6.27-armv5-ixp: ERRORS linux-2.6.28-armv5-ixp: ERRORS linux-2.6.29.1-armv5-ixp: ERRORS linux-2.6.30-armv5-ixp: ERRORS linux-2.6.31-armv5-ixp: ERRORS linux-2.6.32-rc3-armv5-ixp: ERRORS linux-2.6.28-armv5-omap2: OK linux-2.6.29.1-armv5-omap2: OK linux-2.6.30-armv5-omap2: OK linux-2.6.31-armv5-omap2: ERRORS linux-2.6.32-rc3-armv5-omap2: ERRORS linux-2.6.22.19-i686: ERRORS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: ERRORS linux-2.6.25.11-i686: ERRORS linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: WARNINGS linux-2.6.31-i686: WARNINGS linux-2.6.32-rc3-i686: ERRORS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-m32r: OK linux-2.6.31-m32r: OK linux-2.6.32-rc3-m32r: ERRORS linux-2.6.30-mips: WARNINGS linux-2.6.31-mips: OK linux-2.6.32-rc3-mips: ERRORS linux-2.6.27-powerpc64: ERRORS linux-2.6.28-powerpc64: ERRORS linux-2.6.29.1-powerpc64: ERRORS linux-2.6.30-powerpc64: ERRORS linux-2.6.31-powerpc64: ERRORS linux-2.6.32-rc3-powerpc64: ERRORS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.12-x86_64: ERRORS linux-2.6.24.7-x86_64: ERRORS linux-2.6.25.11-x86_64: ERRORS linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: WARNINGS linux-2.6.31-x86_64: WARNINGS linux-2.6.32-rc3-x86_64: ERRORS sparse (linux-2.6.31): OK sparse (linux-2.6.32-rc3): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The V4L2 specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppage WinTV-HVR-900H
Markus Rechberger wrote: Available from 20th Oct on so in 11 days. There are not many competitive devices (none) available for linux which deliver such support. On the other side it's not kernel based either, it's entirely in userspace. It's also entirely supported by all participating companies. this is a mailing list for the open source dvb drivers you are talking about a closed source solution what does your solution have to do with linuxtv.org? nothing -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppage WinTV-HVR-900H
On Fri, Oct 9, 2009 at 11:58 PM, Simon Kenyon si...@koala.ie wrote: Markus Rechberger wrote: Available from 20th Oct on so in 11 days. There are not many competitive devices (none) available for linux which deliver such support. On the other side it's not kernel based either, it's entirely in userspace. It's also entirely supported by all participating companies. this is a mailing list for the open source dvb drivers you are talking about a closed source solution what does your solution have to do with linuxtv.org? I see linux-media, you can find the sources of a patched tvtime version on the website. It shows an alternative way how to integrate usb chipsolutions in linux. Aside of that the official DVB(3/5)/V4L(1/2) API has been reviewed through our work and bugreports have been submitted to various places (linux media, some linux distributions). It integrates flawlessly and helps to improve the overall media support with linux. The posting was pointing out to Ali's email that he was looking for a working analog TV solution for France. He has bought this Pinnacle device 3 years ago, the vendor does not care about support for it. We provide solutions which work within a few seconds, nevermind what distribution. Although this was my last mail addressing your questions. Best Regards, Markus Rechberger -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
