Re: [PATCH] New V4L2 ioctls for OMAP class of Devices
On Tuesday 27 January 2009 05:43:25 Shah, Hardik wrote:
-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Sunday, January 25, 2009 3:06 PM
To: Shah, Hardik
Cc: video4linux-l...@redhat.com; linux-media@vger.kernel.org
Subject: Re: [PATCH] New V4L2 ioctls for OMAP class of Devices
On Saturday 24 January 2009 18:03:51 Shah, Hardik wrote:
-Original Message-
From: Shah, Hardik
Sent: Wednesday, January 21, 2009 5:24 PM
To: video4linux-l...@redhat.com; linux-media@vger.kernel.org
Cc: Shah, Hardik; Jadav, Brijesh R; Nagalla, Hari; Hadli,
Manjunath; R, Sivaraj; Hiremath, Vaibhav
Subject: [PATCH] New V4L2 ioctls for OMAP class of Devices
1. Control ID added for rotation. Same as HFLIP.
2. Control ID added for setting background color on
output device.
3. New ioctl added for setting the color space conversion from
YUV to RGB.
Signed-off-by: Brijesh Jadav brijes...@ti.com
Signed-off-by: Hari Nagalla hnaga...@ti.com
Signed-off-by: Hardik Shah hardik.s...@ti.com
Signed-off-by: Manjunath Hadli m...@ti.com
Signed-off-by: R Sivaraj siva...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
linux/drivers/media/video/v4l2-ioctl.c | 19 ++-
linux/include/linux/videodev2.h| 19 ++-
linux/include/media/v4l2-ioctl.h |4
3 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/linux/drivers/media/video/v4l2-ioctl.c
b/linux/drivers/media/video/v4l2-ioctl.c
index 165bc90..7599da8 100644
--- a/linux/drivers/media/video/v4l2-ioctl.c
+++ b/linux/drivers/media/video/v4l2-ioctl.c
@@ -270,6 +270,8 @@ static const char *v4l2_ioctls[] = {
[_IOC_NR(VIDIOC_DBG_G_CHIP_IDENT)] = VIDIOC_DBG_G_CHIP_IDENT,
[_IOC_NR(VIDIOC_S_HW_FREQ_SEEK)] = VIDIOC_S_HW_FREQ_SEEK,
#endif
+ [_IOC_NR(VIDIOC_S_COLOR_SPACE_CONV)] =
VIDIOC_S_COLOR_SPACE_CONV, + [_IOC_NR(VIDIOC_G_COLOR_SPACE_CONV)]
= VIDIOC_G_COLOR_SPACE_CONV, };
#define V4L2_IOCTLS ARRAY_SIZE(v4l2_ioctls)
@@ -1838,7 +1840,22 @@ static long __video_do_ioctl(struct file
*file, }
break;
}
-
+ case VIDIOC_S_COLOR_SPACE_CONV:
+ {
+ struct v4l2_color_space_conversion *p = arg;
+ if (!ops-vidioc_s_color_space_conv)
+ break;
+ ret = ops-vidioc_s_color_space_conv(file, fh, p);
+ break;
+ }
+ case VIDIOC_G_COLOR_SPACE_CONV:
+ {
+ struct v4l2_color_space_conversion *p = arg;
+ if (!ops-vidioc_g_color_space_conv)
+ break;
+ ret = ops-vidioc_g_color_space_conv(file, fh, p);
+ break;
+ }
default:
{
if (!ops-vidioc_default)
diff --git a/linux/include/linux/videodev2.h
b/linux/include/linux/videodev2.h index b0c5010..9fbc3b0 100644
--- a/linux/include/linux/videodev2.h
+++ b/linux/include/linux/videodev2.h
@@ -879,8 +879,10 @@ enum v4l2_power_line_frequency {
#define V4L2_CID_BACKLIGHT_COMPENSATION(V4L2_CID_BASE+28)
#define V4L2_CID_CHROMA_AGC (V4L2_CID_BASE+29)
#define V4L2_CID_COLOR_KILLER (V4L2_CID_BASE+30)
+#define V4L2_CID_ROTATION (V4L2_CID_BASE+31)
+#define V4L2_CID_BG_COLOR (V4L2_CID_BASE+32)
/* last CID + 1 */
-#define V4L2_CID_LASTP1 (V4L2_CID_BASE+31)
+#define V4L2_CID_LASTP1 (V4L2_CID_BASE+33)
/* MPEG-class control IDs defined by V4L2 */
#define V4L2_CID_MPEG_BASE (V4L2_CTRL_CLASS_MPEG |
0x900)
@@ -1192,6 +1194,17 @@ struct v4l2_hw_freq_seek {
};
/*
+ * Color conversion
+ * User needs to pass pointer to color conversion matrix
+ * defined by hardware
+ */
+struct v4l2_color_space_conversion {
+ __s32 coefficients[3][3];
+ __s32 const_factor;
+ __s32 offsets[3];
+};
+
+/*
* A U D I O
*/
struct v4l2_audio {
@@ -1493,9 +1506,13 @@ struct v4l2_chip_ident_old {
#endif
#define VIDIOC_S_HW_FREQ_SEEK _IOW('V', 82, struct
v4l2_hw_freq_seek) +
+#define VIDIOC_S_COLOR_SPACE_CONV _IOW('V', 83, struct
v4l2_color_space_conversion)
+#define VIDIOC_G_COLOR_SPACE_CONV _IOR('V', 84, struct
v4l2_color_space_conversion)
/* Reminder: when adding new ioctls please add support for them to
drivers/media/video/v4l2-compat-ioctl32.c as well! */
+
#ifdef __OLD_VIDIOC_
/* for compatibility, will go away some day */
#define VIDIOC_OVERLAY_OLD
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-saa7146
On Monday 26 January 2009 23:15:12 Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-saa7146 for the following: - saa7146: fix VIDIOC_ENUMSTD. Also added this high-prio fix: - cx25840: ignore TUNER_SET_CONFIG in the command callback. Something changed in 2.6.29 causing this command to be sent to all i2c devices. Unfortunately, that causes an unwanted firmware load on the cx25840. This fix must go to 2.6.29. Thanks, Hans Thanks, Hans diffstat: saa7146_fops.c |7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: [linux-dvb] getting started with msi tv card
Hi Barry, Sorry about the delay, I was out of town for a few days. I seem to recall that in Australia, use is made of an MHEG service. I don't know if a regular teletext service is available -- you will see this in the results, when you have a tuner capable of scanning. I look forward to finding out... :-) trivially converted to braille or spoken. I'm not sure about Braille..., what format do they originate in? Is it tv signal, or some kind of text guide or something? the MHEG services, as they seem to place more importance on the on-screen appearance, yet they do use a TrueType font. Anyway, while conventional teletext is not simple ASCII-like, it is based on a hamming of a limited character set which can be converted back to a standard 128- or 256-character set font, and of course the normal characters can be displayed as braille. oh... ok Now, here is an example of some of the useful information to be found on a full teletext service, to show that, if it were available to you, you might find it interesting. This is a page giving inter-bank exchange rates from the Euro to your own currency, and is meant as an example (it's in german, but should be trivial to understand) /GIP IG*** PHOENIX Mi 21.01.09 18:01:45 PHOENIX.text 2/2 Devisenkurse Letzte DatenabfrageDiff. Kurs- 21.01.09, 18:00 UhrVortag zeit USA... (USD) 1,2857 -0,20% 17:59 GB (GBP) 0,9369 +0,94% 17:59 Schweiz... (CHF) 1,4767 -0,13% 17:59 Japan. (JPY) 112,9800 -2,35% 17:59 Kanada (CAD) 1,6365 +0,37% 17:59 Südafrika. (ZAR) 13,0970 -1,05% 17:50 Hongkong.. (HKD) 9,9990 +0,07% 17:49 snip Thanks, that looks interesting, so does it all depend on what service is available here in Australia? However, my point is that if this type of service is broadcast in your area, you may find it interesting and useful, as you would be able to make use of the text content within. Indeed, thanks very much. Cheers, Daniel. -- 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: [linux-dvb] getting started with msi tv card
Hi Barry, On Fri, Jan 23, 2009 at 01:41:41AM +0100, BOUWSMA Barry wrote: Basically, this all means that your tuner sees something, but it can't quite lock onto it. Right. Am I better getting a new card? I got this a couple of years ago when I was on windows, and never used it, so yeh I don't have the original aerial that came with it or the original disks... As Antti has suggested, you may have better luck with a new different card. Alright then. As an offside, supposedly the linux-dvb mailing list has been abandoned by every developer, and only a few DVB-freak luddites remain, and in theory, by posting this to the linux-media list I should magically reach thousands of developers who can fix the support for your card. Rght. For these developers, seeing this for the first time, the history behind this thread, including details about the card being discussed, are safely archived on the linux-dvb mailing list over the past three-or-so days. ok I'm connecting it to a co-axle point in my home; I lost the original antenna. I'm reasonably sure that point should work fine. I will take your word for it; you are welcome to still have doubts. However, if others in your home are able to tune digital TV signals, then that pretty much points to your device as having problems. ok In place of the original antenna, you can try a short length of wire, say, 5cm long for the UHF frequency, to about half a metre for the other frequencies. This will, What kind of wire? Ear phone? and how do I hook this up to the receiver since it has a co-axle input plug on it. I have worried that what I write might not work when converted to speech. Probably I should not worry, but be certain that I do not attempt any ASCII graphics that depend on sight, and of a whole screen. If, by mistake, I have done this, please give me the slap I deserve... Nup, you've done a great job. When using mutt and brltty with my braille terminal, I've never come across anything I couldn't read (yet:-)) And that's been over a year. Availability seems to depend a lot on geographic region, so you are going to want to hear from someone also in Australia who can offer suggestions. I'm probably going to buy off ebay. this far, GET A LIFE!!1! I mean, sorry, here is some lol :-) thanks very much Barry, that information is very useful indeed. Have a good one Daniel. -- 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: [PULL] http://linuxtv.org/hg/~mcisely/pvrusb2
On Thu, 22 Jan 2009 22:12:08 +0100 Thierry Merle thierry.me...@free.fr wrote: Laurent Pinchart a écrit : On Thursday 22 January 2009, Carsten Meier wrote: Am Thu, 22 Jan 2009 00:20:00 +0100 schrieb Laurent Pinchart laurent.pinch...@skynet.be: Hi Carsten, On Wednesday 21 January 2009, Carsten Meier wrote: now I want to translate bus_info into a sysfs-path to obtain device-info like serial numbers. Given a device reports usb-:00:1d.2-2 as bus_info, then the device-info is located under /sys/bus/usb/devices/2-2, which is a symlink to the appropriate /sys/devices/ directory, right? I'm afraid not. In the above bus_info value, :00:1d.2 is the PCI bus path of your USB controller, and the last digit after the dash is the USB device path. All I have to do is to compare the first 4 chars of bus_info against usb-, get the chars after . and append it to /sys/bus/usb/devices/ to obatin a sysfs-path, right? Is there a more elegant solution or already a function for this? Can the . appear more than once before the last one? Probably not before, but definitely after. Root hubs get a USB device path set to '0'. Every other device is numbered according to the hub port number it is connected to. If you have an external hub connected on port 2 of your root hub, and have a webcam connected to port 3 of the external hub, usb_make_path() will return usb-:00:1d.2-2.3. Cheers, Laurent Pinchart Hi, On my machine, my pvrusb2 (connected directly to my mini-pc) shows up under /sys/bus/usb/devices/7-2/ which is a symbolic link to ../../../devices/pci:00/:00:1d.7/usb7/7-2 You're just lucky that USB bus 7 (usb7/7) is connected to the 7th function of your USB host controller (1d.7). Here's an example of what I get on my computer: /sys/bus/usb/devices/4-2 - ../../../devices/pci:00/:00:1d.2/usb4/4-2 I can't test for the new bus_info-string, because it's not fixed yet in the driver. But if I got it correctly it should be usb-:00:1d.7-7.2 ? I think you will get usb-:00:1d.7-2 Then I've to simply take the string after the last dash, replace . by - and append it to /sys/bus/usb/devices/ for a sysfs-path? Unfortunately the mapping is not that direct. The part before the last dash identifies the USB host controller. The part after the last dash identifies the device path related to the controller, expressed as a combination of port numbers. The sysfs device path /sys/bus/usb/devices/7-2/ includes a USB bus number (in this case 7) that is not present in usb_make_path()'s output. To find the sysfs path of your USB peripheral, you will have to find out which bus number the bus name (:00:1d.7) corresponds to. You might be able to find that by checking each usb[0-9]+ links in /sys/bus/usb/devices and comparing the link's target with the bus name. To ease this processing, using libsysfs can be a good idea... On my system, the documentation of libsysfs is here: /usr/doc/sysfsutils-2.1.0/libsysfs.txt Knowing the bus-id, it won't be hard to look at it in data structures. Just my 2 cents. Hi Thierry, It may be a good idea to add some code at the v4l2-apps dir for retrieving the sysfs place. Maybe we may add it at qv4l2 and at v4l2-ctl. 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: [PATCH] New V4L2 ioctls for OMAP class of Devices
On Tuesday 27 January 2009 14:02:30 Shah, Hardik wrote:
-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Tuesday, January 27, 2009 2:40 PM
To: Shah, Hardik
Cc: video4linux-l...@redhat.com; linux-media@vger.kernel.org
Subject: Re: [PATCH] New V4L2 ioctls for OMAP class of Devices
On Tuesday 27 January 2009 05:43:25 Shah, Hardik wrote:
-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Sunday, January 25, 2009 3:06 PM
To: Shah, Hardik
Cc: video4linux-l...@redhat.com; linux-media@vger.kernel.org
Subject: Re: [PATCH] New V4L2 ioctls for OMAP class of Devices
On Saturday 24 January 2009 18:03:51 Shah, Hardik wrote:
-Original Message-
From: Shah, Hardik
Sent: Wednesday, January 21, 2009 5:24 PM
To: video4linux-l...@redhat.com; linux-media@vger.kernel.org
Cc: Shah, Hardik; Jadav, Brijesh R; Nagalla, Hari; Hadli,
Manjunath; R, Sivaraj; Hiremath, Vaibhav
Subject: [PATCH] New V4L2 ioctls for OMAP class of Devices
1. Control ID added for rotation. Same as HFLIP.
2. Control ID added for setting background color on
output device.
3. New ioctl added for setting the color space conversion from
YUV to RGB.
Signed-off-by: Brijesh Jadav brijes...@ti.com
Signed-off-by: Hari Nagalla hnaga...@ti.com
Signed-off-by: Hardik Shah hardik.s...@ti.com
Signed-off-by: Manjunath Hadli m...@ti.com
Signed-off-by: R Sivaraj siva...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
linux/drivers/media/video/v4l2-ioctl.c | 19
++- linux/include/linux/videodev2.h|
19 ++- linux/include/media/v4l2-ioctl.h |
4
3 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/linux/drivers/media/video/v4l2-ioctl.c
b/linux/drivers/media/video/v4l2-ioctl.c
index 165bc90..7599da8 100644
--- a/linux/drivers/media/video/v4l2-ioctl.c
+++ b/linux/drivers/media/video/v4l2-ioctl.c
@@ -270,6 +270,8 @@ static const char *v4l2_ioctls[] = {
[_IOC_NR(VIDIOC_DBG_G_CHIP_IDENT)] =
VIDIOC_DBG_G_CHIP_IDENT, [_IOC_NR(VIDIOC_S_HW_FREQ_SEEK)] =
VIDIOC_S_HW_FREQ_SEEK, #endif
+ [_IOC_NR(VIDIOC_S_COLOR_SPACE_CONV)] =
VIDIOC_S_COLOR_SPACE_CONV,
+ [_IOC_NR(VIDIOC_G_COLOR_SPACE_CONV)] =
VIDIOC_G_COLOR_SPACE_CONV, };
#define V4L2_IOCTLS ARRAY_SIZE(v4l2_ioctls)
@@ -1838,7 +1840,22 @@ static long __video_do_ioctl(struct file
*file, }
break;
}
-
+ case VIDIOC_S_COLOR_SPACE_CONV:
+ {
+ struct v4l2_color_space_conversion *p = arg;
+ if (!ops-vidioc_s_color_space_conv)
+ break;
+ ret = ops-vidioc_s_color_space_conv(file, fh, p);
+ break;
+ }
+ case VIDIOC_G_COLOR_SPACE_CONV:
+ {
+ struct v4l2_color_space_conversion *p = arg;
+ if (!ops-vidioc_g_color_space_conv)
+ break;
+ ret = ops-vidioc_g_color_space_conv(file, fh, p);
+ break;
+ }
default:
{
if (!ops-vidioc_default)
diff --git a/linux/include/linux/videodev2.h
b/linux/include/linux/videodev2.h index b0c5010..9fbc3b0 100644
--- a/linux/include/linux/videodev2.h
+++ b/linux/include/linux/videodev2.h
@@ -879,8 +879,10 @@ enum v4l2_power_line_frequency {
#define V4L2_CID_BACKLIGHT_COMPENSATION(V4L2_CID_BASE+28)
#define V4L2_CID_CHROMA_AGC
(V4L2_CID_BASE+29) #define V4L2_CID_COLOR_KILLER
(V4L2_CID_BASE+30) +#define
V4L2_CID_ROTATION (V4L2_CID_BASE+31)
+#define V4L2_CID_BG_COLOR (V4L2_CID_BASE+32)
/* last CID + 1 */
-#define V4L2_CID_LASTP1
(V4L2_CID_BASE+31) +#define V4L2_CID_LASTP1
(V4L2_CID_BASE+33)
/* MPEG-class control IDs defined by V4L2 */
#define V4L2_CID_MPEG_BASE
(V4L2_CTRL_CLASS_MPEG |
0x900)
@@ -1192,6 +1194,17 @@ struct v4l2_hw_freq_seek {
};
/*
+ * Color conversion
+ * User needs to pass pointer to color conversion matrix
+ * defined by hardware
+ */
+struct v4l2_color_space_conversion {
+ __s32 coefficients[3][3];
+ __s32 const_factor;
+ __s32 offsets[3];
+};
+
+/*
* A U D I O
*/
struct v4l2_audio {
@@ -1493,9 +1506,13 @@ struct v4l2_chip_ident_old {
#endif
#define VIDIOC_S_HW_FREQ_SEEK _IOW('V', 82, struct
v4l2_hw_freq_seek) +
Re: [linux-dvb] EC168
Peter Nemeik wrote: Hallo, I am looking for Firmware Drivers for the LogiLink VG0002 USB2.0 DVB-T Stick. There is a Tuner Chip Maxlinear MXL 5003S and a Chip from EC168 (EC168.com) XCMK27819X. I had the Information from the LogiLink Hotline. MXL5003 is supported but EC168 is not. There is no specs for EC168 available. http://tanguy.ath.cx/index.php?q=EC168 Got new stick which is supported. The Software by the Stick is only fpr Windows XP, 2000 and Vista. The Stick is from www.pollin.de http://www.pollin.de/shop/detail.php?pg=NQ==a=NjM5ODI0OTk= Antti -- 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: cx88 audio input change
On Mon, 26 Jan 2009 14:09:31 -0800 LINUX NEWBIE lnxnew...@gmail.com wrote: Hi Mauro, You've been working on cx88 for a long time. Can I ask you something? I have a cx88 based card and I tried to get audio coming from Line In of my card. However, it seems like the audio always comes from TV input. I looked into the code and it seems like VIDIOC_S_AUDIO is not working in cx88. Can you help please? The better is to ask such questions on linux-me...@vger.kernel.org. Anyway, the issue is likely due to a wrong entry at cx88-cards for your board. In order to fix, someone with your board (probably you)should get the proper GPIO pins for your device. Please read the following wiki articles: http://linuxtv.org/wiki/index.php/Development:_How_to_add_support_for_a_device http://linuxtv.org/wiki/index.php/GPIO_pins 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: [PATCH] New V4L2 ioctls for OMAP class of Devices
-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Tuesday, January 27, 2009 2:40 PM
To: Shah, Hardik
Cc: video4linux-l...@redhat.com; linux-media@vger.kernel.org
Subject: Re: [PATCH] New V4L2 ioctls for OMAP class of Devices
On Tuesday 27 January 2009 05:43:25 Shah, Hardik wrote:
-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Sunday, January 25, 2009 3:06 PM
To: Shah, Hardik
Cc: video4linux-l...@redhat.com; linux-media@vger.kernel.org
Subject: Re: [PATCH] New V4L2 ioctls for OMAP class of Devices
On Saturday 24 January 2009 18:03:51 Shah, Hardik wrote:
-Original Message-
From: Shah, Hardik
Sent: Wednesday, January 21, 2009 5:24 PM
To: video4linux-l...@redhat.com; linux-media@vger.kernel.org
Cc: Shah, Hardik; Jadav, Brijesh R; Nagalla, Hari; Hadli,
Manjunath; R, Sivaraj; Hiremath, Vaibhav
Subject: [PATCH] New V4L2 ioctls for OMAP class of Devices
1. Control ID added for rotation. Same as HFLIP.
2. Control ID added for setting background color on
output device.
3. New ioctl added for setting the color space conversion from
YUV to RGB.
Signed-off-by: Brijesh Jadav brijes...@ti.com
Signed-off-by: Hari Nagalla hnaga...@ti.com
Signed-off-by: Hardik Shah hardik.s...@ti.com
Signed-off-by: Manjunath Hadli m...@ti.com
Signed-off-by: R Sivaraj siva...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
linux/drivers/media/video/v4l2-ioctl.c | 19 ++-
linux/include/linux/videodev2.h| 19 ++-
linux/include/media/v4l2-ioctl.h |4
3 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/linux/drivers/media/video/v4l2-ioctl.c
b/linux/drivers/media/video/v4l2-ioctl.c
index 165bc90..7599da8 100644
--- a/linux/drivers/media/video/v4l2-ioctl.c
+++ b/linux/drivers/media/video/v4l2-ioctl.c
@@ -270,6 +270,8 @@ static const char *v4l2_ioctls[] = {
[_IOC_NR(VIDIOC_DBG_G_CHIP_IDENT)] = VIDIOC_DBG_G_CHIP_IDENT,
[_IOC_NR(VIDIOC_S_HW_FREQ_SEEK)] = VIDIOC_S_HW_FREQ_SEEK,
#endif
+ [_IOC_NR(VIDIOC_S_COLOR_SPACE_CONV)] =
VIDIOC_S_COLOR_SPACE_CONV, +
[_IOC_NR(VIDIOC_G_COLOR_SPACE_CONV)]
= VIDIOC_G_COLOR_SPACE_CONV, };
#define V4L2_IOCTLS ARRAY_SIZE(v4l2_ioctls)
@@ -1838,7 +1840,22 @@ static long __video_do_ioctl(struct file
*file, }
break;
}
-
+ case VIDIOC_S_COLOR_SPACE_CONV:
+ {
+ struct v4l2_color_space_conversion *p = arg;
+ if (!ops-vidioc_s_color_space_conv)
+ break;
+ ret = ops-vidioc_s_color_space_conv(file, fh, p);
+ break;
+ }
+ case VIDIOC_G_COLOR_SPACE_CONV:
+ {
+ struct v4l2_color_space_conversion *p = arg;
+ if (!ops-vidioc_g_color_space_conv)
+ break;
+ ret = ops-vidioc_g_color_space_conv(file, fh, p);
+ break;
+ }
default:
{
if (!ops-vidioc_default)
diff --git a/linux/include/linux/videodev2.h
b/linux/include/linux/videodev2.h index b0c5010..9fbc3b0 100644
--- a/linux/include/linux/videodev2.h
+++ b/linux/include/linux/videodev2.h
@@ -879,8 +879,10 @@ enum v4l2_power_line_frequency {
#define V4L2_CID_BACKLIGHT_COMPENSATION (V4L2_CID_BASE+28)
#define V4L2_CID_CHROMA_AGC (V4L2_CID_BASE+29)
#define V4L2_CID_COLOR_KILLER (V4L2_CID_BASE+30)
+#define V4L2_CID_ROTATION(V4L2_CID_BASE+31)
+#define V4L2_CID_BG_COLOR(V4L2_CID_BASE+32)
/* last CID + 1 */
-#define V4L2_CID_LASTP1 (V4L2_CID_BASE+31)
+#define V4L2_CID_LASTP1 (V4L2_CID_BASE+33)
/* MPEG-class control IDs defined by V4L2 */
#define V4L2_CID_MPEG_BASE (V4L2_CTRL_CLASS_MPEG |
0x900)
@@ -1192,6 +1194,17 @@ struct v4l2_hw_freq_seek {
};
/*
+ * Color conversion
+ * User needs to pass pointer to color conversion matrix
+ * defined by hardware
+ */
+struct v4l2_color_space_conversion {
+ __s32 coefficients[3][3];
+ __s32 const_factor;
+ __s32 offsets[3];
+};
+
+/*
* A U D I O
*/
struct v4l2_audio {
@@ -1493,9 +1506,13 @@ struct v4l2_chip_ident_old {
#endif
#define VIDIOC_S_HW_FREQ_SEEK _IOW('V', 82, struct
v4l2_hw_freq_seek) +
+#define VIDIOC_S_COLOR_SPACE_CONV _IOW('V', 83, struct
v4l2_color_space_conversion)
+#define VIDIOC_G_COLOR_SPACE_CONV
Re: [linux-dvb] How to use scan-s2?
In message 1233017978.3061.2.ca...@palomino.walls.org, Andy Walls wrote:
LO
On Mon, 2009-01-26 at 22:31 +0200, Alex Betis wrote:
On Mon, Jan 26, 2009 at 10:20 PM, Darron Broad dar...@kewl.org
wrote:
In message
c74595dc0901261130k6bdb6882lfb18c650cbca4...@mail.gmail.com,
Alex
Betis wrote:
On Mon, Jan 26, 2009 at 7:32 PM, Darron Broad
dar...@kewl.org wrote:
In message
c74595dc0901260753x8b9185fu33f2a96ffbe13...@mail.gmail.com,
Alex Betis wrote:
lo
snip
The bug is in S2API that doesn't return ANY error message
at all :)
Aside from Darron's observation, doesn't the result field of any
particular S2API property return with a non-0 value on failure?
(Sorry, I missed the original thread on the S2API return values.)
The actual tuning occurs within a thread and not when issuing
the tuning IOCTL. The only means to determine whether tuning
worked or not is inspection of the frontend events generated
within that thread. So, if the params are wrong, the IOCTL
can fail, but that's not the problem Alex is experiencing
where the params are correctly formed yet not supported in
the driver.
I did look at a means to expose supported params a while ago
but it's ugly so I haven't gone forward with it.
Bye
--
// /
{:)==={ Darron Broad dar...@kewl.org
\\ \
--
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: [RFC] Adding new ioctl for transparency color keying
-Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Tuesday, January 27, 2009 6:38 PM To: Shah, Hardik Cc: linux-media@vger.kernel.org; video4linux-l...@redhat.com Subject: Re: [RFC] Adding new ioctl for transparency color keying On Tuesday 27 January 2009 13:53:23 Shah, Hardik wrote: -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Tuesday, January 27, 2009 3:21 PM To: Shah, Hardik Cc: linux-media@vger.kernel.org; video4linux-l...@redhat.com Subject: Re: [RFC] Adding new ioctl for transparency color keying Hi Hardik, On Thursday 22 January 2009 05:57:18 Shah, Hardik wrote: Hi, OMAP class of device supports transparency color keying. Color keying can be source color keying or destination color keying. Can it be both as well? OMAP3 has three pipelines one graphics plane and two video planes. Any of these pipelines can go to either the TV or LCD. The destination transparency color key value defines the encoded pixels in the graphics layer to become transparent and display the underlying video pixels. While the source transparency key value defines the encoded pixels in the video layer to become transparent and display the underlying graphics pixels. This color keying works only if the video and graphics planes are on the same output like TV or LCD and images of both the pipelines overlapped. I propose to have the one ioctl to set the encoded pixel value and type of color keying source and destination. Also we should have the CID to enable/disable the color keying functionality. Please let us know your opinions/comments. Destination color keying is already available through the S_FBUF and S_FMT ioctls. Selecting source color keying can easily be added to S_FBUF, but setting the actual chromakey is harder. The logical place would be the v4l2_pix_format struct, but that is already full. I guess we should make a new control to set the source chromakey. It's not ideal, but it prevents duplicating existing functionality. [Shah, Hardik] Hi Hans, This has nothing to do with the frame buffer. Transparency key is a hardware provided feature. Driver has just to give the color code and whether it wants the source color keying or destination color keying. Hardware will automatically make the color code transparent so that the below layer color will be seen. So I don't think so that S_FBUF is suitable for this kind of feature. And this will automatically take effect if the graphics pipeline is on the same output device as the video pipeline. Why has this nothing to do with the framebuffer? Isn't there a /dev/fbX device for the graphics framebuffer? If there is, then it is exactly as I described: a video output overlay (aka OSD). Do not confuse this with a video overlay which is used to accelerate displaying captured video. See also: http://www.linuxtv.org/downloads/video4linux/API/V4L2_API/spec- single/v4l2.html#OSD [Shah, Hardik] Hi Hans, Here the graphics node is created for the graphics pipeline. And graphics pipeline will be controlled by the graphics node /dev/fbx. Application will set the desired pixel format for the /dev/fbx node and /dev/v4l/videox node. After that application can select that same output device for both the nodes. And then user may want to make transparent either the color from the video pipeline of the graphics pipeline. In any case application will not require frame buffer parameters like base address of the buffer as the blending/transparency processing will not be done in driver. It will be done by hardware by setting the appropriate register bits. So do you think that S_FBUF is required? Please let me know if I am missing something.If you want I can forward you the link referring to the Technical reference manual explaining the color keying in hardware. Regards, Hardik Shah Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: [RFC] Adding new ioctl for transparency color keying
On Tuesday 27 January 2009 15:09:34 Shah, Hardik wrote: -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Tuesday, January 27, 2009 6:38 PM To: Shah, Hardik Cc: linux-media@vger.kernel.org; video4linux-l...@redhat.com Subject: Re: [RFC] Adding new ioctl for transparency color keying On Tuesday 27 January 2009 13:53:23 Shah, Hardik wrote: -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Tuesday, January 27, 2009 3:21 PM To: Shah, Hardik Cc: linux-media@vger.kernel.org; video4linux-l...@redhat.com Subject: Re: [RFC] Adding new ioctl for transparency color keying Hi Hardik, On Thursday 22 January 2009 05:57:18 Shah, Hardik wrote: Hi, OMAP class of device supports transparency color keying. Color keying can be source color keying or destination color keying. Can it be both as well? OMAP3 has three pipelines one graphics plane and two video planes. Any of these pipelines can go to either the TV or LCD. The destination transparency color key value defines the encoded pixels in the graphics layer to become transparent and display the underlying video pixels. While the source transparency key value defines the encoded pixels in the video layer to become transparent and display the underlying graphics pixels. This color keying works only if the video and graphics planes are on the same output like TV or LCD and images of both the pipelines overlapped. I propose to have the one ioctl to set the encoded pixel value and type of color keying source and destination. Also we should have the CID to enable/disable the color keying functionality. Please let us know your opinions/comments. Destination color keying is already available through the S_FBUF and S_FMT ioctls. Selecting source color keying can easily be added to S_FBUF, but setting the actual chromakey is harder. The logical place would be the v4l2_pix_format struct, but that is already full. I guess we should make a new control to set the source chromakey. It's not ideal, but it prevents duplicating existing functionality. [Shah, Hardik] Hi Hans, This has nothing to do with the frame buffer. Transparency key is a hardware provided feature. Driver has just to give the color code and whether it wants the source color keying or destination color keying. Hardware will automatically make the color code transparent so that the below layer color will be seen. So I don't think so that S_FBUF is suitable for this kind of feature. And this will automatically take effect if the graphics pipeline is on the same output device as the video pipeline. Why has this nothing to do with the framebuffer? Isn't there a /dev/fbX device for the graphics framebuffer? If there is, then it is exactly as I described: a video output overlay (aka OSD). Do not confuse this with a video overlay which is used to accelerate displaying captured video. See also: http://www.linuxtv.org/downloads/video4linux/API/V4L2_API/spec- single/v4l2.html#OSD [Shah, Hardik] Hi Hans, Here the graphics node is created for the graphics pipeline. And graphics pipeline will be controlled by the graphics node /dev/fbx. Application will set the desired pixel format for the /dev/fbx node and /dev/v4l/videox node. After that application can select that same output device for both the nodes. And then user may want to make transparent either the color from the video pipeline of the graphics pipeline. In any case application will not require frame buffer parameters like base address of the buffer as the blending/transparency processing will not be done in driver. It will be done by hardware by setting the appropriate register bits. So do you think that S_FBUF is required? Please let me know if I am missing something.If you want I can forward you the link referring to the Technical reference manual explaining the color keying in hardware. Yes, this is exactly the same as is implemented for ivtv: ivtvfb is the framebuffer driver for the OSD and ivtv implements G/S_FBUF to set the framebuffer parameters like chromakeying. Note that the fb.h API knows nothing about video, so that cannot be used to set chromakeys and such. This has to be done from the V4L2 API. And the struct v4l2_framebuffer passed to VIDIOC_G/S_FBUF is how you do it. The capability field tells you what the device supports in the way of clipping and transparencies. The flags field lets the application select how to do e.g. transparency. The base field can be used in the case of OSDs to discover with fbX device belongs to the video device. Section 4.4.2 in the V4L2 spec shows how to do that. And finally the fmt field will tell you how the framebuffer is organized. Through VIDIOC_S_FMT and struct v4l2_window you
Re: [linux-dvb] getting started with msi tv card
On Tue, 27 Jan 2009, Daniel Dalton wrote: [Now, ideally, a teletext service, being text-based, can be] trivially converted to braille or spoken. I'm not sure about Braille..., what format do they originate in? Is it tv signal, or some kind of text guide or something? The teletext service I hope you would be able to get, is sent as part of the digital service. Here I will quickly explain that a Transport Stream, which is used by DVB-T, mixes together digital versions of several services, including audio soundtrack, or radio, as well as video signals, and additional data services, with each component being able to be identified by its own ID. A conventional set-top-box will convert the video from its digital form to an analogue equivalent, then convert the audio soundtrack into its analogue form, and decode and add the teletext to the video signal, perhaps also including its own internal teletext decoder for user convenience. Then these analogue signals are delivered to your tv by one of many means, be it as an RGB signal through a SCART connector, or in the worst case, by modulating an RF carrier. But your Linux machine will be working with the Transport Stream directly, selecting the particular IDs of interest. When you look at that particular ID, you see merely a datastream including the payload. So, just as your TV audio will be carried in a form which will be similar to the mp3 files you've certainly used, or whatever format, you can also write the teletext data to a file and work with that. When you get your tuner working, or one that does, if you do receive a teletext service, I'll guide you through the steps needed to actually see the content being broadcast. As a little teaser, I will paste part of a hexdump of an update to today's rates of the example I posted earlier. 01c0 20 20 20 20 20 cb 61 6e 61 64 61 ae ae ae ae 20 | .anada | 01d0 a8 43 c1 c4 29 83 20 20 31 2c b6 31 38 37 02 20 |.C..). 1,.187. | 01e0 ab b0 2c b3 37 25 07 31 32 ba b0 37 20 d3 fd 64 |..,.7%.12..7 ..d| 01f0 61 e6 f2 e9 6b 61 ae 20 a8 da c1 52 29 83 20 31 |a...ka. ...R). 1| 0200 b3 2c b3 37 b6 31 02 20 ab b0 2c b5 b6 25 07 31 |.,.7.1. ..,..%.1| 0210 31 ba b5 b0 20 c8 ef 6e 67 6b ef 6e 67 ae ae 20 |1... ..ngk.ng.. | 0220 a8 c8 cb c4 29 83 20 31 b0 2c 32 b5 b6 37 02 20 |). 1.,2..7. | 0230 ab b0 2c 31 b6 25 07 31 31 ba 34 b9 20 d3 e9 6e |..,1.%.11.4. ..n| There are some readable parts of words (Canada, Hongkong) to be seen in the ASCII dump at the right, but it is not quite a simple text dump. The program I hacked to display this in text form does the conversion into ASCII with the added characters for the particular language in use. So, to answer your question, essentially it is a text guide. Now, the MHEG service, in contrast, is Java based, and I have downloaded a good number of files, both text and binary, that would be used to display a particular page. However, I can't see a simple way to get at the text info within and display it. That would be for someone who has studied and understands this service. Thanks, that looks interesting, so does it all depend on what service is available here in Australia? That is correct. One more thing I should note, is that this text type of teletext supports, and broadcasters generally make heavy use of, features such as colours, double-height and blinking characters, and in particular, parts of character blocks that can be used to create simple graphics. Think of some sort of ASCII art, or, with the most common use made of these graphics by commercial broadcasters, ASCII pr0n. DANGER! ASCII PR0N PASTED BELOW! SENSITIVE READERS SHOULD AVERT THEIR GAZE OR SKIP TO THE NEXT MESSAGE! ^L I MEAN IT! IT COULD QUALIFY AS EXTREME PORN! ^L THAT'S IT, I TAKE NO RESPONSIBILITY FOR YOUR ACTIONS! This pr0n is made worse by the fact that my console font does not include the full range of teletext partial blocks, so I've substituted characters such as `*' and `X' to try and give a feel for how the graphics should appear. Maybe a full Unicode X font will include such characters and I can simply map them to UTF8, but I'm primarily interested in the text content information on my text console. Here's the pr0n... █X█X*XX*???*?██ XXX*AMI █X?█??*█ █X?* █ ** No, this is not going to work. There are too many characters which are not yet converted to something and I'm having to add as `?' by hand. Anyway, the blocks on the left are used to form words; to the right the blocks would be forming the top of a female head. auszuziehen.Magst *X*███XX*██ Du mir die Kleider *XXX* ██ vom Leib reissen? XX██* X█* At the right, part of a stomach and arm Well, anyway, if these non-ASCII full blocks have made it through intact and are diplaying correctly anywhere,
RE: [PATCH] New V4L2 ioctls for OMAP class of Devices
On Tue, 27 Jan 2009, Shah, Hardik wrote: The rotation values are 0, 90, 180 and 270 degree but to disable rotation the value passed should be -1 and this is one more value. I know 0 degree rotation corresponds to rotation disabled but DSS hardware requires 0 degree rotation to be enabled for mirroring. The difference between the 0 degree rotation and no rotation(-1) is that 0 degree rotation will use the rotation engine in OMAP and then do the mirroring while -1 degree rotation will not use rotation engine. There is more bandwidth utilization while using the rotation engine. So people may want to completely disable rotation and people may want 0 degree rotation for mirroring support. That's why I prefer not to use enum. Is that ok for That sounds like a hardware quirk that the driver should take care of. Just have the driver turn on the rotation engine if mirroring is used. It seems very hard for an application to make decent use of rotation support if only certain values are supported by the hardware yet anything in degrees can be specified? How is the application supposed to know what values will be acceptable? -- 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: [PATCH] New V4L2 ioctls for OMAP class of Devices
On Tue, 27 Jan 2009, Hans Verkuil wrote:
[Shah, Hardik] Hi Hans,
I got your above point. Now regarding the enum I am not sure about how
to implement it. Are you suggesting me to remove the control ID for
rotation and implement in some other way. Please let me know if I am
missing something. Currently in driver I have implemented the rotation in
below way {
.id= V4L2_CID_ROTATION,
.name = Rotation,
.minimum = 0,
.maximum = 270,
.step = 90,
.default_value = -1,
.flags = 0,
.type = V4L2_CTRL_TYPE_INTEGER,
You want me to change V4L2_CTRL_TYPE_INTEGER to some enum or something.
Change it to V4L2_CTRL_TYPE_MENU. See:
http://www.linuxtv.org/downloads/video4linux/API/V4L2_API/spec-single/v4l2.html#VIDIOC-QUERYCTRL
Thinking about it more, I think an integer control like this might make
more sense. default_value should be changed to 0 of course. Extracting
the real meaning from the control setting is more obvious for the integer
control than a menu. And what if some hardware allows for rotations other
than 90 degrees?
--
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: [PATCH] New V4L2 ioctls for OMAP class of Devices
On Tue, 27 Jan 2009, Hans Verkuil wrote:
On Tuesday 27 January 2009 19:08:43 Trent Piepho wrote:
On Tue, 27 Jan 2009, Hans Verkuil wrote:
[Shah, Hardik] Hi Hans,
I got your above point. Now regarding the enum I am not sure about
how to implement it. Are you suggesting me to remove the control ID
for rotation and implement in some other way. Please let me know if
I am missing something. Currently in driver I have implemented the
rotation in below way {
.id= V4L2_CID_ROTATION,
.name = Rotation,
.minimum = 0,
.maximum = 270,
.step = 90,
.default_value = -1,
.flags = 0,
.type = V4L2_CTRL_TYPE_INTEGER,
You want me to change V4L2_CTRL_TYPE_INTEGER to some enum or
something.
Change it to V4L2_CTRL_TYPE_MENU. See:
http://www.linuxtv.org/downloads/video4linux/API/V4L2_API/spec-single/v
4l2.html#VIDIOC-QUERYCTRL
Thinking about it more, I think an integer control like this might make
more sense. default_value should be changed to 0 of course. Extracting
the real meaning from the control setting is more obvious for the integer
control than a menu. And what if some hardware allows for rotations
other than 90 degrees?
If the hardware can do rotations other than 90 degrees then we get into the
area of video effects. In principle such a driver can implement this
rotation control as an integer rather than a menu (apps are supposed to
query the type of a control dynamically, after all). But for a case like
this where there are only four values I think a menu-type control is much
more user-friendly.
How so? An application can easily tell from the range and step of the
integer control that there are only four values. And it can easily tell
what the values mean. For instance if the app wants to show icons for the
rotations or have a command line parameter rotation in degrees, it's easy
to figure out what value the control should be set to. For a menu, what is
the app supposed to do? Call atoi() on the menu entry names and hope that
they parse corretly? Seems like a kludge to do that.
--
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: [PULL] http://linuxtv.org/hg/~mcisely/pvrusb2
Hi Carsten, On Tue, 27 Jan 2009 14:56:26 +0100 Carsten Meier c...@trexity.de wrote: Hi Thierry, It may be a good idea to add some code at the v4l2-apps dir for retrieving the sysfs place. Maybe we may add it at qv4l2 and at v4l2-ctl. Cheers, Mauro Hi, here is code which I've written for it. It is in C++ with Boost, but adaption to C shouldn't be hard. It's not extensively tested and put into the public domain. Thank you for your code. I've converted it to C, and improved it to work also with PCI and PCIe devices. I've made it available at: http://linuxtv.org/hg/v4l-dvb/rev/6e636c8969e8 (and two subsequent patches improving it a little bit) Maybe it is of use for one or another. For now, it is a separate small application. This makes easy for scripts to use it. It will output both the raw data returned by VIDIOC_QUERYCAP and their sysfs path: For a USB device: device = /dev/video0 bus info = usb-:00:1d.7-1 sysfs path = /sys/devices/pci:00/:00:1d.7/usb2/2-1 For a PCI device: device = /dev/video0 bus info = PCI::01:02.0 sysfs path = /sys/devices/pci:00/:00:1e.0/:01:02.0 It works even with devices with internal PCI bridges, like this one: device = /dev/video4 bus info = PCI::02:0f.0 sysfs path = /sys/devices/pci:00/:00:1e.0/:01:01.0/:02:0f.0 device = /dev/video3 bus info = PCI::02:0e.0 sysfs path = /sys/devices/pci:00/:00:1e.0/:01:01.0/:02:0e.0 device = /dev/video2 bus info = PCI::02:0d.0 sysfs path = /sys/devices/pci:00/:00:1e.0/:01:01.0/:02:0d.0 device = /dev/video1 bus info = PCI::02:0c.0 sysfs path = /sys/devices/pci:00/:00:1e.0/:01:01.0/:02:0c.0 I tested here with bttv (a board with 4 bttv chips), saa7134, uvcvideo and em28xx. It should work fine also with other devices. 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: saa716x compile warnings
Jan Engelhardt wrote: Hi, I noticed in a forum post that the saa716x driver spews warnings on x86_64: http://www.linux-club.de/viewtopic.php?f=41t=100240 /home/johnny/Documents/saa716x-e9cc5826649c/v4l/saa716x_dma.c:129: warning: cast from pointer to integer of different size as I look into the code (tip just moments ago), that seems to be largely true: /* align memory to page */ dmabuf-mem_virt = (void *) PAGE_ALIGN (((u32) dmabuf-mem_virt_noalign)); I always recommend building it not only on x86 to catch such errors. Truncating to (u32) is likely to be wrong for 64-bit systems! Fixed now. Thanks, Manu -- 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: [linux-dvb] Upcoming DVB-T channel changes for HH (Hamburg)
Hi, hermann pitton schrieb: The reverse effect will be, we have it already with federal state scan files now, that we likely will see more questions about why the hell I don't get this one and tuning failed ... Regarding the de-Sachsen-Anhalt file, apart from 3 or 4 frequency entries the rest is useless being within the state, because regarding transmitters the areas are mostly not coordinated. Brocken and Magdeburg are the only sites with Sachsen-Anhalt that are corrdinated. In fact, it is more common, that transmitters here are coordinated with sites from others states, e.g. ARD-Das Erste multiplex in Halle/Saale (Sachsen-Anhalt/Saxony-Anhalt) are coordinated with Leipzig (Sachsen/Saxony) and Gera (Thüringen/Thuringia), because this area is also topographically adjunct. ZDF multiplex is coordinated between Hale/Saale and Leipzig ... To share a center frequency over several federal states under such conditions seems to be plain wrong and I wonder if there was a rule. This does not matter, as the transmitters in Brauschweig (Niedersachsen/Lower Saxony) and Halle/Saale (Sachsen-Anhalt) don't interfere with each other (the sites are more than 140 km apart) and there is a buffer zone of about 40 - 50 km between them, where you need a directed roof antenna to either receive one of them. As I've experienced so far while travelling, that there are only very small parts in my federal state (Bundesland) of Sachsen-Anhalt where one can receive more than one transmitter site (and in most of this cases, a roof antenna is required, so you would normally have to direct this to a specific transmitter). Well, I believe both scenarios(scan file for federal state versus scan file for a DVB-T region) have their pros and cons. :( Fortunately programs like Kaffeine offer a full auto scan ... Regards, Tobias -- 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: [linux-dvb] Dallas Texas ATSC scan file
This is just a small subset of the available frequencies where we may find ATSC services. Although this may be helpful for people scanning in Dallas, TX today, it will cause problems when the services move to other frequencies. This will only scan a very limited range of frequencies, so naturally, it will be much quicker, but you might miss some services. Users should use the file, us-ATSC-center-frequencies-8VSB , which contains all of the frequencies below, along with the full frequency table for ATSC, from channels 2 through 69. I wouldn't commit this file, for the same very reason that I deleted the TWCNYC file. Regards, Mike Christoph Pfister wrote: Mike, Can I have your $0.02, please? Thanks, Christoph 2009/1/24 Jorge Canas jcanas2...@hotmail.com: # DALLAS TX ATSC center frequencies, use if in doubt A 189028615 8VSB A 473028615 8VSB A 497028615 8VSB A 503028615 8VSB A 533028615 8VSB A 569028615 8VSB A 581028615 8VSB A 599028615 8VSB A 605028615 8VSB A 629028615 8VSB A 635028615 8VSB A 641028615 8VSB A 659028615 8VSB A 665028615 8VSB A 677028615 8VSB A 695028615 8VSB -- 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
Unicode Teletext (was: Re: [linux-dvb] getting started with msi tv card)
On Wed, 28 Jan 2009, Daniel Dalton wrote:
Maybe a full Unicode X font will include such characters
and I can simply map them to UTF8, but I'm primarily
interested in the text content information on my text console.
Here's the pr0n...
???X???X*XX*???*??? XXX*AMI
???X??*??? ???X?* ??? **
No, this is not going to work. There are too many characters
which are not yet converted to something and I'm having to add
ah, ok... I kinda get it... :-)
Actually, your `mutt' mailer has managed to convert the
UTF-8 encoding which I hope you received into ASCII and
substituted its own `?' for those block characters which
should have appeared as correct UTF-8, though I'll need to
check an archive.
And after quite a few too many hours, I still don't get it,
and I'm going to have to ask help from the collective
knowledge pooled here.
I've seen that the 10646 encoded fonts available usually
have the familiar box-drawing and related characters I've
partly been able to use for a few of the graphics.
Unfortunately, these seem to be either based on a 2x2 set
of quads, or a 3x4 array. While the teletext graphics in
use uses a 2x3 array.
I've come upon two sets of fonts which supposedly cover
the teletext character set with a 10646 encoding. But
the first one, which does include the 2x3 graphics chars
that otherwise need a `fontspecific' encoding, seems to
have hijacked existing assigned unicode characters in
order to display the graphics.
That is, with this font, these characters no longer display
properly (selection limited due to pasting from a 512-char
console font)
[◆] U+25C6 #9670; BLACK DIAMOND
[◊] U+25CA #9674; LOZENGE
This is matched by reading the code:
const wchar_t graphutf8[128] = { // Graphic characters on an unicode terminal
ISO-10646
[...]
0x25A0,0x25A1,0x25A2,0x25A3,0x25A4,0x25A5,0x25A6,0x25A7,
[...]
0x25B0,0x25B1,0x25B2,0x25B3,0x25B4,0x25B5,0x25B6,0x25B7,
[...]
0x25C0,0x25C1,0x25C2,0x25c3,0x25C4,0x25C5,0x25C6,0x25C7,
[...]
0x25D8,0x25D9,0x25DA,0x25DB,0x25DC,0x25DD,0x25DE,0x25DF,
};
I'm still trying to determine whether the second font has any
graphics and where they would be hidden -- even the handy
[█] U+2588 #9608; FULL BLOCK
character is missing.
Does anyone know whether the various 2x3 graphics used in
teletext fonts are in fact present in Unicode? I haven't
been able to convince google to give me the answer I want.
I would think that with everything I do see with a unifont
font, that such widely-used characters wouldn't have been
left out...
thanks for any pointers,
barry bouwsma
--
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: [RFC] Adding new ioctl for transparency color keying
-Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Tuesday, January 27, 2009 8:07 PM To: Shah, Hardik Cc: linux-media@vger.kernel.org; video4linux-l...@redhat.com Subject: Re: [RFC] Adding new ioctl for transparency color keying On Tuesday 27 January 2009 15:09:34 Shah, Hardik wrote: -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Tuesday, January 27, 2009 6:38 PM To: Shah, Hardik Cc: linux-media@vger.kernel.org; video4linux-l...@redhat.com Subject: Re: [RFC] Adding new ioctl for transparency color keying On Tuesday 27 January 2009 13:53:23 Shah, Hardik wrote: -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Tuesday, January 27, 2009 3:21 PM To: Shah, Hardik Cc: linux-media@vger.kernel.org; video4linux-l...@redhat.com Subject: Re: [RFC] Adding new ioctl for transparency color keying Hi Hardik, On Thursday 22 January 2009 05:57:18 Shah, Hardik wrote: Hi, OMAP class of device supports transparency color keying. Color keying can be source color keying or destination color keying. Can it be both as well? OMAP3 has three pipelines one graphics plane and two video planes. Any of these pipelines can go to either the TV or LCD. The destination transparency color key value defines the encoded pixels in the graphics layer to become transparent and display the underlying video pixels. While the source transparency key value defines the encoded pixels in the video layer to become transparent and display the underlying graphics pixels. This color keying works only if the video and graphics planes are on the same output like TV or LCD and images of both the pipelines overlapped. I propose to have the one ioctl to set the encoded pixel value and type of color keying source and destination. Also we should have the CID to enable/disable the color keying functionality. Please let us know your opinions/comments. Destination color keying is already available through the S_FBUF and S_FMT ioctls. Selecting source color keying can easily be added to S_FBUF, but setting the actual chromakey is harder. The logical place would be the v4l2_pix_format struct, but that is already full. I guess we should make a new control to set the source chromakey. It's not ideal, but it prevents duplicating existing functionality. [Shah, Hardik] Hi Hans, This has nothing to do with the frame buffer. Transparency key is a hardware provided feature. Driver has just to give the color code and whether it wants the source color keying or destination color keying. Hardware will automatically make the color code transparent so that the below layer color will be seen. So I don't think so that S_FBUF is suitable for this kind of feature. And this will automatically take effect if the graphics pipeline is on the same output device as the video pipeline. Why has this nothing to do with the framebuffer? Isn't there a /dev/fbX device for the graphics framebuffer? If there is, then it is exactly as I described: a video output overlay (aka OSD). Do not confuse this with a video overlay which is used to accelerate displaying captured video. See also: http://www.linuxtv.org/downloads/video4linux/API/V4L2_API/spec- single/v4l2.html#OSD [Shah, Hardik] Hi Hans, Here the graphics node is created for the graphics pipeline. And graphics pipeline will be controlled by the graphics node /dev/fbx. Application will set the desired pixel format for the /dev/fbx node and /dev/v4l/videox node. After that application can select that same output device for both the nodes. And then user may want to make transparent either the color from the video pipeline of the graphics pipeline. In any case application will not require frame buffer parameters like base address of the buffer as the blending/transparency processing will not be done in driver. It will be done by hardware by setting the appropriate register bits. So do you think that S_FBUF is required? Please let me know if I am missing something.If you want I can forward you the link referring to the Technical reference manual explaining the color keying in hardware. Yes, this is exactly the same as is implemented for ivtv: ivtvfb is the framebuffer driver for the OSD and ivtv implements G/S_FBUF to set the framebuffer parameters like chromakeying. Note that the fb.h API knows nothing about video, so that cannot be used to set chromakeys and such. This has to be done from the V4L2 API. And the struct v4l2_framebuffer passed to VIDIOC_G/S_FBUF is how you do it. The capability field tells you what the device supports in the way of clipping and transparencies.
