[PATCH] V4L: fix ENUMSTD ioctl to report all supported standards
V4L2_STD_PAL, V4L2_STD_SECAM, and V4L2_STD_NTSC are not the only composite standards. Currently, e.g., if a driver supports all of V4L2_STD_PAL_B, V4L2_STD_PAL_B1 and V4L2_STD_PAL_G, the enumeration will report V4L2_STD_PAL_BG and not the single standards, which can confuse applications. Fix this by only clearing simple standards from the mask. This, of course, will only work, if composite standards are listed before simple ones in the standards array in v4l2-ioctl.c, which is currently the case. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c index 4b11257..2389df0 100644 --- a/drivers/media/video/v4l2-ioctl.c +++ b/drivers/media/video/v4l2-ioctl.c @@ -1065,9 +1065,7 @@ static long __video_do_ioctl(struct file *file, j++; if (curr_id == 0) break; - if (curr_id != V4L2_STD_PAL - curr_id != V4L2_STD_SECAM - curr_id != V4L2_STD_NTSC) + if (is_power_of_2(curr_id)) id = ~curr_id; } if (i = index) -- 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: PCTV 73eSE driver not loaded
Devin, The build process was not complete indeed. Dropping FiredTV made it successful - the rest of the story is positive; everything running smooth. Many thanks! Luc. - Oorspronkelijk bericht - Van: Devin Heitmueller dheitmuel...@kernellabs.com Aan: luc boschmans luc.boschm...@newtec.eu Cc: linux-media@vger.kernel.org Verzonden: Woensdag 24 maart 2010 16:35:23 GMT +01:00 Amsterdam / Berlijn / Bern / Rome / Stockholm / Wenen Onderwerp: Re: PCTV 73eSE driver not loaded On Wed, Mar 24, 2010 at 11:10 AM, luc.boschm...@newtec.eu wrote: All, I am a Linux newbie trying to install a PCTV 73eSE DVB-T receiver, but the driver apparently does not get loaded. These are the 'cookbook' steps I followed: -Fresh Ubuntu 9.10 distribution installed. -kernel upgraded to 2.6.31-20-generic (using Ubuntu upgrade tool) -Mercurial installed -V4L-DVB kernel modules downloaded (source) -make (screen output attached) -make install -reboot (with the DVB-T USB dongle attached during boot) Outcome: -There is no /dev/dvb directory -/proc/modules does not list any relevant reference to the PCTV 73eSE USB dongle (apparently the correct driver for that should be the DIB0700 driver) Looking at the mailing list, there is some history on the PCTV 73eSE device: apparently this was originally owned by Pinnacle; the same device can have 2 different manuf ID's. Posts on the list (nov / dec 2009) point out that corrections have been done to support both manuf ID's. The relevant lsusb -v output is: Bus 001 Device 003: ID 2013:0245 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x2013 idProduct 0x0245 bcdDevice 1.00 iManufacturer 1 PCTV Systems iProduct 2 PCTV 73e SE iSerial 3 000M99B4P6Q bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 46 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 4 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 bNumConfigurations 1 Device Status: 0x (Bus Powered) The vendor ID in my case apparently is 0x2013. I am able to find back this ID in the source files (but I am not a programmer), so it looks as if this is not the reason why the driver doens't get loaded. Nevertheless, the 'automagic' part of udev seems to have abandoned me:) Any idea's to proceed on this? Thanks in advance, Luc Boschmans. A couple of quick things: Your build doesn't look complete. Did you manually run make menuconfig and pick
Re: [PATCH] V4L: fix ENUMSTD ioctl to report all supported standards
Guennadi Liakhovetski wrote:
V4L2_STD_PAL, V4L2_STD_SECAM, and V4L2_STD_NTSC are not the only composite
standards. Currently, e.g., if a driver supports all of V4L2_STD_PAL_B,
V4L2_STD_PAL_B1 and V4L2_STD_PAL_G, the enumeration will report
V4L2_STD_PAL_BG and not the single standards, which can confuse
applications. Fix this by only clearing simple standards from the mask.
This, of course, will only work, if composite standards are listed before
simple ones in the standards array in v4l2-ioctl.c, which is currently
the case.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
The patch looks sane to me. Yet, as it assumes the the standards array will
follow
an specific construction rule, please add a comment before the array with the
rule.
I doubt we would have any new analog standard added there, but yet, someone
might
have the bright idea of sending a patch to reorder it with some different logic
as
a cleanup patch.
-
PS.: For the others that also want to review this patch, assuming that all PAL
and
SECAM formats are supported, after the patch, it will also enumerate the
following
video standards:
PAL-B
PAL-B1
PAL-G
PAL-D
PAL-D1
PAL-K
SECAM-D
SECAM-K
SECAM-K1
While the code is short, the logic behind it is somewhat complex, as the routine
will return the i-th element of an array of video standards.
The better way to test if the logic is properly working is to run it from
userspace, playing with the supported standards.
To save people some time, I've enclosed a simple test program that
could be used for that purpose, that I used on my review.
Playing with STD define and see the diffs between the old and the new code is
as simple as:
$ gcc -Wall -o test_std test_std.c ./test_std old old ./test_std new
diff --unified=0 old new
A similar procedure can be done to compare the diff between the code with all
standards and all but some standards.
---
#include stdio.h
#include string.h
#include sys/types.h
#include linux/videodev2.h
//#define STD V4L2_STD_ALL
#define STD V4L2_STD_ALL (~V4L2_STD_PAL_D1)
//#define STD V4L2_STD_ALL (~V4L2_STD_SECAM_LC)
int is_power_of_2(unsigned long n)
{
return (n != 0 ((n (n - 1)) == 0));
}
struct std_descr {
v4l2_std_id std;
const char *descr;
};
static const struct std_descr standards[] = {
{ V4L2_STD_NTSC,NTSC },
{ V4L2_STD_NTSC_M, NTSC-M},
{ V4L2_STD_NTSC_M_JP, NTSC-M-JP },
{ V4L2_STD_NTSC_M_KR, NTSC-M-KR },
{ V4L2_STD_NTSC_443,NTSC-443 },
{ V4L2_STD_PAL, PAL },
{ V4L2_STD_PAL_BG, PAL-BG},
{ V4L2_STD_PAL_B, PAL-B },
{ V4L2_STD_PAL_B1, PAL-B1},
{ V4L2_STD_PAL_G, PAL-G },
{ V4L2_STD_PAL_H, PAL-H },
{ V4L2_STD_PAL_I, PAL-I },
{ V4L2_STD_PAL_DK, PAL-DK},
{ V4L2_STD_PAL_D, PAL-D },
{ V4L2_STD_PAL_D1, PAL-D1},
{ V4L2_STD_PAL_K, PAL-K },
{ V4L2_STD_PAL_M, PAL-M },
{ V4L2_STD_PAL_N, PAL-N },
{ V4L2_STD_PAL_Nc, PAL-Nc},
{ V4L2_STD_PAL_60, PAL-60},
{ V4L2_STD_SECAM, SECAM },
{ V4L2_STD_SECAM_B, SECAM-B },
{ V4L2_STD_SECAM_G, SECAM-G },
{ V4L2_STD_SECAM_H, SECAM-H },
{ V4L2_STD_SECAM_DK,SECAM-DK },
{ V4L2_STD_SECAM_D, SECAM-D },
{ V4L2_STD_SECAM_K, SECAM-K },
{ V4L2_STD_SECAM_K1,SECAM-K1 },
{ V4L2_STD_SECAM_L, SECAM-L },
{ V4L2_STD_SECAM_LC,SECAM-Lc },
{ 0,Unknown }
};
const char *v4l2_norm_to_name(v4l2_std_id id)
{
int i;
for (i = 0; standards[i].std; i++)
if (id == standards[i].std)
break;
return standards[i].descr;
}
int main(int argc, char *argv[])
{
v4l2_std_id curr_id, id = STD;
unsigned int i, j = 0;
const char *descr = ;
int old = 0;
if (argc == 2 !strcasecmp(argv[1],old))
old = 1;
printf (%s code\n, old? old:new);
{
/* Use here the code on __video_do_ioctl for ENUMSTD */
/* Return norm array in a canonical way */
for (i = 0; id; i++) {
/* last std value in the standards array is 0, so this
while always ends there since (id 0) == 0. */
while ((id standards[j].std) != standards[j].std)
j++;
curr_id = standards[j].std;
descr = standards[j].descr;
j++;
if (curr_id == 0)
break;
if (old) {
if (curr_id != V4L2_STD_PAL
curr_id !=
Avermedia AVerTV GO 007 FM composite input problem
hi i have a Avermedia AVerTV GO 007 FM card , the problem is that i get nothing from Composite, i tried different apps (mplayer, tvtime, etc) none works. (television input works) ideas? here're some infos [9.361212] saa7130/34: v4l2 driver version 0.2.15 loaded [9.361631] alloc irq_desc for 17 on node -1 [9.361635] alloc kstat_irqs on node -1 [9.361648] saa7134 :00:09.0: PCI INT A - GSI 17 (level, low) - IRQ 17 [9.361768] saa7133[0]: found at :00:09.0, rev: 208, irq: 17, latency: 32, mmio: 0xcfffc800 [9.361955] saa7133[0]: subsystem: 1461:f31f, board: Avermedia AVerTV GO 007 FM [card=57,autodetected] [9.362198] saa7133[0]: board init: gpio is 8 [9.362424] input: saa7134 IR (Avermedia AVerTV GO as /devices/pci:00/:00:09.0/input/input6 [9.362713] IRQ 17/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs [9.501011] saa7133[0]: i2c eeprom 00: 61 14 1f f3 ff ff ff ff ff ff ff ff ff ff ff ff [9.501838] saa7133[0]: i2c eeprom 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.502592] saa7133[0]: i2c eeprom 20: ff d2 fe ff ff ff ff ff ff ff ff ff ff ff ff ff [9.503343] saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.504095] saa7133[0]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.504842] saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.505593] saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.506345] saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.507097] saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.507846] saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.508600] saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.509354] saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.510107] saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.510920] saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.511672] saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.512423] saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 10.780106] tuner 0-004b: chip found @ 0x96 (saa7133[0]) [ 10.815008] tda829x 0-004b: setting tuner address to 61 [ 11.349012] tda829x 0-004b: type set to tda8290+75 [ 14.869150] saa7133[0]: registered device video0 [v4l2] [ 14.869305] saa7133[0]: registered device vbi0 [ 14.869447] saa7133[0]: registered device radio0 [ 14.968864] saa7134 ALSA driver for DMA sound loaded [ 14.970728] IRQ 17/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs [ 14.970892] saa7133[0]/alsa: saa7133[0] at 0xcfffc800 irq 17 registered as card -1 $ v4l-info ### v4l2 device info [/dev/video0] ### general info VIDIOC_QUERYCAP driver : saa7134 card: Avermedia AVerTV GO 007 FM bus_info: PCI::00:09.0 version : 0.2.15 capabilities: 0x5010015 [VIDEO_CAPTURE,VIDEO_OVERLAY,VBI_CAPTURE,TUNER,READWRITE,STREAMING] standards VIDIOC_ENUMSTD(0) index : 0 id : 0xb000 [NTSC_M,NTSC_M_JP,?] name: NTSC frameperiod.numerator : 1001 frameperiod.denominator : 3 framelines : 525 VIDIOC_ENUMSTD(1) index : 1 id : 0x1000 [NTSC_M] name: NTSC-M frameperiod.numerator : 1001 frameperiod.denominator : 3 framelines : 525 VIDIOC_ENUMSTD(2) index : 2 id : 0x2000 [NTSC_M_JP] name: NTSC-M-JP frameperiod.numerator : 1001 frameperiod.denominator : 3 framelines : 525 VIDIOC_ENUMSTD(3) index : 3 id : 0x8000 [?] name: NTSC-M-KR frameperiod.numerator : 1001 frameperiod.denominator : 3 framelines : 525 VIDIOC_ENUMSTD(4) index : 4 id : 0xff [PAL_B,PAL_B1,PAL_G,PAL_H,PAL_I,PAL_D,PAL_D1,PAL_K] name: PAL frameperiod.numerator : 1 frameperiod.denominator : 25 framelines : 625 VIDIOC_ENUMSTD(5) index : 5 id : 0x7 [PAL_B,PAL_B1,PAL_G] name: PAL-BG frameperiod.numerator : 1 frameperiod.denominator : 25 framelines : 625 VIDIOC_ENUMSTD(6) index : 6 id
Re: [PATCH] V4L: fix ENUMSTD ioctl to report all supported standards
On Fri, 26 Mar 2010, Hans Verkuil wrote: On Friday 26 March 2010 08:06:42 Guennadi Liakhovetski wrote: V4L2_STD_PAL, V4L2_STD_SECAM, and V4L2_STD_NTSC are not the only composite standards. Currently, e.g., if a driver supports all of V4L2_STD_PAL_B, V4L2_STD_PAL_B1 and V4L2_STD_PAL_G, the enumeration will report V4L2_STD_PAL_BG and not the single standards, which can confuse applications. Fix this by only clearing simple standards from the mask. This, of course, will only work, if composite standards are listed before simple ones in the standards array in v4l2-ioctl.c, which is currently the case. Do you have an specific example where the current implementation will do the wrong thing? Yes - sh_vou with gstreamer. gstreamer enumerates standards and gest PAL_BG but not PAL_B or PAL_G. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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: Andy Walls' change of email address
On Thu, 2010-03-25 at 15:41 +0100, HoP wrote: 2010/3/25 Jay R. Ashworth j...@baylink.com: - HoP jpetr...@gmail.com wrote: My radix.net email address will soon cease working. of course it is not my job, but I wonder why you not stay on old email. In 21 century there is no problem to move domain to other place or, at least, do some type of forwarding :) Radix.net by default does forwarding for 30 days. My 2 cents /Honza PS: The only real reason I can imagine is that radix.com is not your own domain and owner of it doesn't allow mail forwarding. Which is, indeed, what one finds by pointing a browser at www.radix.net; that mailbox belongs to his old ISP, and presumably he doesn't want to keep paying them for it. Yes. The value of keeping my old address, to me, is not worth the periodic charge to keep it active. A simple case of cost vs. benefit not meeting my threshold. TBH I would imagine radix.net can be proud if so well-know developer is using theirs domain. May be they would pay for his advertising :) Thank you. :) I never asked them. Quite honestly I think Radix is a great local ISP. One of the first to provide real coverage to Southern Maryland, IIRC. I think local ISPs provide the better customer service, and Radix.net was no exception. Regards, Andy -- 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] ov7670 changes
Jonathan Corbet wrote: Hi, Mauro, With luck, I'll shortly have a via-camera driver (for the XO 1.5) ready for review. In the mean time, though, here's a set of ov7670 changes which have built up in the process. Unless there are objections, I'd appreciate it if these could go in for 2.6.35. Hi Jon, The patches look sane and were already applied on my tree. I'm now getting some warnings while compiling it with allyesconfig: drivers/media/video/ov7670.c: In function ‘ov7670_s_parm’: drivers/media/video/ov7670.c:877: warning: unused variable ‘ret’ drivers/media/video/ov7670.c:876: warning: unused variable ‘clkrc’ drivers/media/video/ov7670.c: In function ‘ov7670_g_autoexp’: drivers/media/video/ov7670.c:1279: warning: unused variable ‘atype’ Anyway, I'll be adding them to linux-next. Please send me later a cleanup. 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 2/3 v2] V4L: v4l2-subdev driver for AK8813 and AK8814 TV-encoders from AKM
On Thursday 18 March 2010 11:28:32 Guennadi Liakhovetski wrote:
diff --git a/drivers/media/video/ak881x.c b/drivers/media/video/ak881x.c
...
+static int ak881x_s_std_output(struct v4l2_subdev *sd, v4l2_std_id std)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct ak881x *ak881x = to_ak881x(client);
+ u8 vp1;
+
+ switch (std) {
+ case V4L2_STD_NTSC_M:
+ default:
+ vp1 = 0;
+ ak881x-lines = 480;
+ break;
+ case V4L2_STD_NTSC_443:
+ vp1 = 3;
+ ak881x-lines = 480;
+ break;
+ case V4L2_STD_PAL_M:
+ vp1 = 5;
+ ak881x-lines = 480;
+ break;
+ case V4L2_STD_PAL_60:
+ vp1 = 7;
+ ak881x-lines = 480;
+ break;
+ case V4L2_STD_PAL_B:
+ case V4L2_STD_PAL_D:
+ case V4L2_STD_PAL_G:
+ case V4L2_STD_PAL_H:
+ case V4L2_STD_PAL_I:
+ vp1 = 0xf;
+ ak881x-lines = 576;
+ }
+
+ reg_set(client, AK881X_VIDEO_PROCESS1, vp1, 0xf);
+
+ return 0;
+}
This is not correct. The std is a bitmask but multiple bits can be set
(and usually are). In general this should be written like this:
if (std == V4L2_STD_NTSC_443) {
vp1 = 3;
ak881x-lines = 480;
} else if (std == V4L2_STD_PAL_M) {
...
} else if (std == V4L2_STD_PAL_60) {
...
} else if (std V4L2_STD_PAL) {
...
} else if (std V4L2_STD_NTSC) {
...
} else {
/* No SECAM or PAL_N/Nc supported */
return -EINVAL;
}
In all modern video encoders or decoders all PAL variants are handled
automatically. Only some very old tuners have restrictions.
I would also be surprised if this device didn't handle SECAM as well.
Changing the code like this will also fix the problem you had with ENUMSTD.
Requiring applications to show the full list of all variants is something
the end user will not understand (heck, *I* wouldn't understand either!).
My experience is that the list of formats that really matter is this:
NTSC
NTSC-443
PAL-M
PAL-N
PAL-Nc
PAL-60
(PAL-I in rare cases)
PAL (all others)
SECAM-BGH
SECAM-DK
SECAM-L
(SECAM-Lc is no longer used in practice)
In the case of S-Video/Composite input or output this list is even shorter:
NTSC-443
NTSC
PAL-M
PAL-N
PAL-Nc
PAL-60
PAL
SECAM
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: [PATCH] V4L: fix ENUMSTD ioctl to report all supported standards
On Friday 26 March 2010 12:24:26 Guennadi Liakhovetski wrote: On Fri, 26 Mar 2010, Hans Verkuil wrote: On Friday 26 March 2010 08:06:42 Guennadi Liakhovetski wrote: V4L2_STD_PAL, V4L2_STD_SECAM, and V4L2_STD_NTSC are not the only composite standards. Currently, e.g., if a driver supports all of V4L2_STD_PAL_B, V4L2_STD_PAL_B1 and V4L2_STD_PAL_G, the enumeration will report V4L2_STD_PAL_BG and not the single standards, which can confuse applications. Fix this by only clearing simple standards from the mask. This, of course, will only work, if composite standards are listed before simple ones in the standards array in v4l2-ioctl.c, which is currently the case. Do you have an specific example where the current implementation will do the wrong thing? Yes - sh_vou with gstreamer. gstreamer enumerates standards and gest PAL_BG but not PAL_B or PAL_G. See my review of the ak881x tv-encoder. This ENUMSTD patch just papers over a bug in the ak881x driver. So the real fix has to be done there and not here. This patch would otherwise lead to an unmanagable mess of videostandards for the end-user. Regards, Hans Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 -- 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
[no subject]
unsubscribe linux-media -- 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] What are the goals for the architecture of an in-kernel IR system?
On Thu, Mar 25, 2010 at 07:32:59PM +0100, Pavel Machek wrote:
struct keycode_table_entry {
unsigned keycode;
int len;
char scancode[];
}
? gcc extension, but commonly used around kernel.
Flexible array members are ok in C99, aren't they?
--
David Härdeman
--
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] What are the goals for the architecture of an in-kernel IR system?
On Thu, Mar 25, 2010 at 11:42:33AM -0300, Mauro Carvalho Chehab wrote: 2) add current_protocol support on other drivers; Done. Patch were already merged upstream. The current_protocol attribute shows the protocol(s) that the device is accepting and allows changing it to another protocol. In the case of the em28xx hardware, only one protocol can be active, since the decoder is inside the hardware. On the raw IR decode implementation I've done at the saa7134, all raw pulse events are sent to all registered decoders, so I'm thinking on using this sysfs node to allow disabling the standard behavior of passing the IR codes to all decoders, routing it to just one decoder. Another alternative would be to show current_protocol only for devices with hardware decoder, and create one sysfs node for each decoder, allowing enabling/disabling each decoder individually. You're eventually going to want to add ioctl's to set a lot of TX or RX parameters in one go (stuff like active receiver(s) and transmitter(s), carrier frequency, duty cycle, timeouts, filter levels and resolution - all of which would need to be set in one operation since some hardware will need to be reset after each parameter is changed). Then you'll end up with a few things being controlled via sysfs and some being controlled via ioctls. Maybe it's a good idea to have a bitmask of supported and enabled protocols in those ioctls instead? -- David Härdeman -- 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] What are the goals for the architecture of an in-kernel IR system?
On Thu, Mar 25, 2010 at 11:42:33AM -0300, Mauro Carvalho Chehab wrote:
10) extend keycode table replacement to support big/variable
sized scancodes;
Pending.
The current limit here is the scancode ioctl's are defined as:
#define EVIOCGKEYCODE _IOR('E', 0x04, int[2]) /*
get keycode */
#define EVIOCSKEYCODE _IOW('E', 0x04, int[2]) /*
set keycode */
As int size is 32 bits, and we must pass both 64 (or even bigger) scancodes,
associated
with a keycode, there's not enough bits there for IR.
The better approach seems to create an struct with an arbitrary long size,
like:
struct keycode_table_entry {
unsigned keycode;
char scancode[32]; /* 32 is just an arbitrary long array - maybe
shorter */
int len;
}
and re-define the ioctls. For example we might be doing:
#define EVIOCGKEYCODEBIG _IOR('E', 0x04, struct keycode_table_entry)
#define EVIOCSKEYCODEBIG _IOW('E', 0x04, struct keycode_table_entry)
#define EVIOCLEARKEYCODEBIG_IOR('E', 0x04, void)
Provided that the size for struct keycode_table_entry is different, _IO will
generate
a different magic number for those.
Or, instead of using 0x04, just use another sequential number at the 'E'
namespace.
An specific function to clear the table is needed with big scancode space,
as already discussed.
I'd suggest:
struct keycode_table_entry {
unsigned keycode;
unsigned index;
unsigned len;
char scancode[];
};
Use index in EVIOCGKEYCODEBIG to look up a keycode (all other fields are
ignored), that way no special function to clear the table is necessary,
instead you do a loop with:
EVIOCGKEYCODEBIG (with index 0)
EVIOCSKEYCODEBIG (with the returned struct from EVIOCGKEYCODEBIG and
keycode = KEY_RESERVED)
until EVIOCGKEYCODEBIG returns an error.
This also allows you to get all the current mappings from the kernel
without having to blindly search through an arbitrarily large keyspace.
Also, EVIOCLEARKEYCODEBIG should be:
#define EVIOCLEARKEYCODEBIG _IOR('E', 0x04, struct keycode_table_entry)
That way a user space application can simply call EVIOCLEARKEYCODEBIG,
ask the user for an appropriate keycode, fill in the keycode member of
the struct returned from EVIOCLEARKEYCODEBIG and call EVIOCSKEYCODEBIG.
On a related note, I really think the interface would benefit from
allowing more than one keytable per irrcv device with an input device
created per keytable. That way you can have one input device per remote
control. This implies that EVIOCLEARKEYCODEBIG is a bit misplaced as an
evdev IOCTL since there's an N-1 mapping between input devices and irrcv
devices.
ioctl's to set/get keycodes for ir should also take a flag parameter in
the struct to allow special properties to be set/returned for a given
keycode mapping (I'm thinking of keycodes which powers on the computer
for instance, that should be exposed to userspace somehow).
With all of that, the struct might need to be something like:
struct keycode_table_entry {
unsigned keycode; /* e.g. KEY_A */
unsigned table; /* Table index, for multiple keytables */
unsigned index; /* Index in the given keytable */
unsigned flags; /* For additional functionality */
unsigned len; /* Of the struct */
char scancode[]; /* Per-protocol scancode data follows */
};
Finally, I think irrcv should create a chardev of its own with ioctl's
like EVIOCLEARKEYCODEBIG (and RX/TX parameter setting ioctl's). The
same chardev can be used for IR blasting (by writing data to it once TX
parameters have been set).
--
David Härdeman
--
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] What are the goals for the architecture of an in-kernel IR system?
David Härdeman wrote:
On Thu, Mar 25, 2010 at 11:42:33AM -0300, Mauro Carvalho Chehab wrote:
10) extend keycode table replacement to support big/variable
sized scancodes;
Pending.
The current limit here is the scancode ioctl's are defined as:
#define EVIOCGKEYCODE _IOR('E', 0x04, int[2]) /*
get keycode */
#define EVIOCSKEYCODE _IOW('E', 0x04, int[2]) /*
set keycode */
As int size is 32 bits, and we must pass both 64 (or even bigger) scancodes,
associated
with a keycode, there's not enough bits there for IR.
The better approach seems to create an struct with an arbitrary long size,
like:
struct keycode_table_entry {
unsigned keycode;
char scancode[32]; /* 32 is just an arbitrary long array - maybe
shorter */
int len;
}
and re-define the ioctls. For example we might be doing:
#define EVIOCGKEYCODEBIG _IOR('E', 0x04, struct
keycode_table_entry)
#define EVIOCSKEYCODEBIG _IOW('E', 0x04, struct
keycode_table_entry)
#define EVIOCLEARKEYCODEBIG_IOR('E', 0x04, void)
Provided that the size for struct keycode_table_entry is different, _IO will
generate
a different magic number for those.
Or, instead of using 0x04, just use another sequential number at the 'E'
namespace.
An specific function to clear the table is needed with big scancode space,
as already discussed.
I'd suggest:
struct keycode_table_entry {
unsigned keycode;
unsigned index;
unsigned len;
char scancode[];
};
Use index in EVIOCGKEYCODEBIG to look up a keycode (all other fields are
ignored), that way no special function to clear the table is necessary,
instead you do a loop with:
EVIOCGKEYCODEBIG (with index 0)
EVIOCSKEYCODEBIG (with the returned struct from EVIOCGKEYCODEBIG and
keycode = KEY_RESERVED)
until EVIOCGKEYCODEBIG returns an error.
Makes sense.
This also allows you to get all the current mappings from the kernel
without having to blindly search through an arbitrarily large keyspace.
Also, EVIOCLEARKEYCODEBIG should be:
#define EVIOCLEARKEYCODEBIG _IOR('E', 0x04, struct keycode_table_entry)
That way a user space application can simply call EVIOCLEARKEYCODEBIG,
ask the user for an appropriate keycode, fill in the keycode member of
the struct returned from EVIOCLEARKEYCODEBIG and call EVIOCSKEYCODEBIG.
By using the index concept, I don't think we need another ioctl. Also,
there's no way for kernel to handle it, as it will be using the same
magic number of EVIOCGKEYCODEBIG.
On a related note, I really think the interface would benefit from
allowing more than one keytable per irrcv device with an input device
created per keytable. That way you can have one input device per remote
control. This implies that EVIOCLEARKEYCODEBIG is a bit misplaced as an
evdev IOCTL since there's an N-1 mapping between input devices and irrcv
devices.
I don't think that an ioctl over one /dev/input/event should be the proper way
to ask kernel to create another filtered /dev/input/event. As it were commented
that the multimedia keys on some keyboards could benefit on having a filter
capability, maybe we may have a sysfs node at class input that would allow
the creation/removal of the filtered event interface.
ioctl's to set/get keycodes for ir should also take a flag parameter in
the struct to allow special properties to be set/returned for a given
keycode mapping (I'm thinking of keycodes which powers on the computer
for instance, that should be exposed to userspace somehow).
With all of that, the struct might need to be something like:
struct keycode_table_entry {
unsigned keycode; /* e.g. KEY_A */
unsigned table; /* Table index, for multiple keytables */
unsigned index; /* Index in the given keytable */
unsigned flags; /* For additional functionality */
unsigned len; /* Of the struct */
char scancode[]; /* Per-protocol scancode data follows */
};
I don't see the need for a table index. If we have 3 input event interfaces
for a given IR, each will have its own private keycode table.
Finally, I think irrcv should create a chardev of its own with ioctl's
like EVIOCLEARKEYCODEBIG (and RX/TX parameter setting ioctl's). The
same chardev can be used for IR blasting (by writing data to it once TX
parameters have been set).
There are several different things mixed above. It may be a good idea
to allow extending the ioctls from the input event device to other input
classes. Yet, I'm currently not seeing any usage for it.
In the specific case of EVIOCGKEYCODEBIG/EVIOCSKEYCODEBIG, those are needed
for all input devices whose scancode is bigger than 32 bits. It is not
specific to IR.
I don't think we need to add ioctl's to change RX/TX parameters. The better
is to do it via sysfs. I've added yesterday one of such parameter for the
nec
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
David Härdeman wrote: On Thu, Mar 25, 2010 at 11:42:33AM -0300, Mauro Carvalho Chehab wrote: 2) add current_protocol support on other drivers; Done. Patch were already merged upstream. The current_protocol attribute shows the protocol(s) that the device is accepting and allows changing it to another protocol. In the case of the em28xx hardware, only one protocol can be active, since the decoder is inside the hardware. On the raw IR decode implementation I've done at the saa7134, all raw pulse events are sent to all registered decoders, so I'm thinking on using this sysfs node to allow disabling the standard behavior of passing the IR codes to all decoders, routing it to just one decoder. Another alternative would be to show current_protocol only for devices with hardware decoder, and create one sysfs node for each decoder, allowing enabling/disabling each decoder individually. You're eventually going to want to add ioctl's to set a lot of TX or RX parameters in one go (stuff like active receiver(s) and transmitter(s), carrier frequency, duty cycle, timeouts, filter levels and resolution - all of which would need to be set in one operation since some hardware will need to be reset after each parameter is changed). TX is a completely different history. It has nothing to do with input event subsystem. So, another approach should be taken for it. I haven't seen yet a hardware decoder with such parameters, but maybe I just don't have enough specs here to adjust them. Anyway, one simple way to avoid resetting the hardware for every new parameter change would be to use a timer for reset. This way, an userspace application or script that is touching on several parameters would just send the complete RX init sequence and after some dozens of milliseconds, the hardware will load the new parameters. Then you'll end up with a few things being controlled via sysfs and some being controlled via ioctls. Maybe it's a good idea to have a bitmask of supported and enabled protocols in those ioctls instead? There's an interesting discussion about bitmasks x a list of enumerated values as a way to represent a bitmask into a series of values on sysfs, at http://lwn.net/Articles/378219/ (see A critical look at sysfs attribute values article there). That's said, I'm starting to think that the better is to have some differentiation there between hardware and software decoders. IMO, software decoders are better handled with an enabled attribute, per software decoder, inside each irrcv. In the case of hardware decoders, just one attribute is enough to control it. I think it should be a bitmask parameter, but presented with their aliases, like for example: $cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors ondemand conservative performance This is clearly a bitmask, but it is presented as textual values, instead of a magic number. So, we may have /sys/class/irrcv/irrcv0/supported_protocols as, for example: RC-5 NEC and allow setting current_protocol as just RC-5 or, if the hardware supports more than one decoder at the same time, as RC-5 NEC. -- 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: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Fri, Mar 26, 2010 at 11:40:41AM -0300, Mauro Carvalho Chehab wrote:
David Härdeman wrote:
On Thu, Mar 25, 2010 at 11:42:33AM -0300, Mauro Carvalho Chehab wrote:
10) extend keycode table replacement to support big/variable
sized scancodes;
Pending.
The current limit here is the scancode ioctl's are defined as:
#define EVIOCGKEYCODE _IOR('E', 0x04, int[2]) /*
get keycode */
#define EVIOCSKEYCODE _IOW('E', 0x04, int[2]) /*
set keycode */
As int size is 32 bits, and we must pass both 64 (or even bigger)
scancodes, associated
with a keycode, there's not enough bits there for IR.
The better approach seems to create an struct with an arbitrary long size,
like:
struct keycode_table_entry {
unsigned keycode;
char scancode[32]; /* 32 is just an arbitrary long array - maybe
shorter */
int len;
}
and re-define the ioctls. For example we might be doing:
#define EVIOCGKEYCODEBIG _IOR('E', 0x04, struct
keycode_table_entry)
#define EVIOCSKEYCODEBIG _IOW('E', 0x04, struct
keycode_table_entry)
#define EVIOCLEARKEYCODEBIG_IOR('E', 0x04, void)
Provided that the size for struct keycode_table_entry is different, _IO
will generate
a different magic number for those.
Or, instead of using 0x04, just use another sequential number at the 'E'
namespace.
An specific function to clear the table is needed with big scancode space,
as already discussed.
I'd suggest:
struct keycode_table_entry {
unsigned keycode;
unsigned index;
unsigned len;
char scancode[];
};
Use index in EVIOCGKEYCODEBIG to look up a keycode (all other fields are
ignored), that way no special function to clear the table is necessary,
instead you do a loop with:
EVIOCGKEYCODEBIG (with index 0)
EVIOCSKEYCODEBIG (with the returned struct from EVIOCGKEYCODEBIG and
keycode = KEY_RESERVED)
until EVIOCGKEYCODEBIG returns an error.
Makes sense.
Yes, I think so too. Just need a nice way to handle transition, I'd
like in the end to have drivers implement only the improved methods and
map legacy methods in evdev.
This also allows you to get all the current mappings from the kernel
without having to blindly search through an arbitrarily large keyspace.
Also, EVIOCLEARKEYCODEBIG should be:
#define EVIOCLEARKEYCODEBIG _IOR('E', 0x04, struct keycode_table_entry)
That way a user space application can simply call EVIOCLEARKEYCODEBIG,
ask the user for an appropriate keycode, fill in the keycode member of
the struct returned from EVIOCLEARKEYCODEBIG and call EVIOCSKEYCODEBIG.
By using the index concept, I don't think we need another ioctl. Also,
there's no way for kernel to handle it, as it will be using the same
magic number of EVIOCGKEYCODEBIG.
On a related note, I really think the interface would benefit from
allowing more than one keytable per irrcv device with an input device
created per keytable. That way you can have one input device per remote
control. This implies that EVIOCLEARKEYCODEBIG is a bit misplaced as an
evdev IOCTL since there's an N-1 mapping between input devices and irrcv
devices.
I don't think that an ioctl over one /dev/input/event should be the proper way
to ask kernel to create another filtered /dev/input/event. As it were
commented
that the multimedia keys on some keyboards could benefit on having a filter
capability, maybe we may have a sysfs node at class input that would allow
the creation/removal of the filtered event interface.
No, if you want separate event devices just create a new instance of
input device for every keymap and have driver/irrcv class route events
to proper input device.
Thanks.
--
Dmitry
--
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] ov7670 changes
On Fri, 26 Mar 2010 08:35:16 -0300 Mauro Carvalho Chehab mche...@infradead.org wrote: I'm now getting some warnings while compiling it with allyesconfig: Sigh...I don't really reserve all of my silly mistakes for you...it just must seem that way. Fix can be pulled from the same tree: git://git.lwn.net/linux-2.6.git ov7670 or can be found attached. Sorry for the noise. jon --- ov7670: silence some compiler warnings Get rid of some unused variable warnings. These were the result of sloppiness and should not have happened; I'll go stand in the corner now. Reported-by: Mauro Carvalho Chehab mche...@infradead.org Signed-off-by: Jonathan Corbet cor...@lwn.net --- drivers/media/video/ov7670.c |7 +++ 1 files changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/media/video/ov7670.c b/drivers/media/video/ov7670.c index a3fee6a..798b4c9 100644 --- a/drivers/media/video/ov7670.c +++ b/drivers/media/video/ov7670.c @@ -873,8 +873,7 @@ static int ov7670_s_parm(struct v4l2_subdev *sd, struct v4l2_streamparm *parms) struct v4l2_captureparm *cp = parms-parm.capture; struct v4l2_fract *tpf = cp-timeperframe; struct ov7670_info *info = to_state(sd); - unsigned char clkrc; - int ret, div; + int div; if (parms-type != V4L2_BUF_TYPE_VIDEO_CAPTURE) return -EINVAL; @@ -1280,9 +1279,9 @@ static int ov7670_g_autoexp(struct v4l2_subdev *sd, __s32 *value) ret = ov7670_read(sd, REG_COM8, com8); if (com8 COM8_AEC) - *value = V4L2_EXPOSURE_AUTO; + *atype = V4L2_EXPOSURE_AUTO; else - *value = V4L2_EXPOSURE_MANUAL; + *atype = V4L2_EXPOSURE_MANUAL; return ret; } -- 1.7.0.1 -- 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] What are the goals for the architecture of an in-kernel IR system?
Dmitry Torokhov wrote:
On Fri, Mar 26, 2010 at 11:40:41AM -0300, Mauro Carvalho Chehab wrote:
David Härdeman wrote:
On Thu, Mar 25, 2010 at 11:42:33AM -0300, Mauro Carvalho Chehab wrote:
10) extend keycode table replacement to support big/variable
sized scancodes;
Pending.
The current limit here is the scancode ioctl's are defined as:
#define EVIOCGKEYCODE _IOR('E', 0x04, int[2]) /*
get keycode */
#define EVIOCSKEYCODE _IOW('E', 0x04, int[2]) /*
set keycode */
As int size is 32 bits, and we must pass both 64 (or even bigger)
scancodes, associated
with a keycode, there's not enough bits there for IR.
The better approach seems to create an struct with an arbitrary long size,
like:
struct keycode_table_entry {
unsigned keycode;
char scancode[32]; /* 32 is just an arbitrary long array - maybe
shorter */
int len;
}
and re-define the ioctls. For example we might be doing:
#define EVIOCGKEYCODEBIG _IOR('E', 0x04, struct
keycode_table_entry)
#define EVIOCSKEYCODEBIG _IOW('E', 0x04, struct
keycode_table_entry)
#define EVIOCLEARKEYCODEBIG_IOR('E', 0x04, void)
Provided that the size for struct keycode_table_entry is different, _IO
will generate
a different magic number for those.
Or, instead of using 0x04, just use another sequential number at the 'E'
namespace.
An specific function to clear the table is needed with big scancode space,
as already discussed.
I'd suggest:
struct keycode_table_entry {
unsigned keycode;
unsigned index;
unsigned len;
char scancode[];
};
Use index in EVIOCGKEYCODEBIG to look up a keycode (all other fields are
ignored), that way no special function to clear the table is necessary,
instead you do a loop with:
EVIOCGKEYCODEBIG (with index 0)
EVIOCSKEYCODEBIG (with the returned struct from EVIOCGKEYCODEBIG and
keycode = KEY_RESERVED)
until EVIOCGKEYCODEBIG returns an error.
Makes sense.
Yes, I think so too. Just need a nice way to handle transition, I'd
like in the end to have drivers implement only the improved methods and
map legacy methods in evdev.
Ok. I'll prepare the patches for adding the new ioctl, in a way that it will
also handle the legacy methods, and post for review.
On a related note, I really think the interface would benefit from
allowing more than one keytable per irrcv device with an input device
created per keytable. That way you can have one input device per remote
control. This implies that EVIOCLEARKEYCODEBIG is a bit misplaced as an
evdev IOCTL since there's an N-1 mapping between input devices and irrcv
devices.
I don't think that an ioctl over one /dev/input/event should be the proper
way
to ask kernel to create another filtered /dev/input/event. As it were
commented
that the multimedia keys on some keyboards could benefit on having a filter
capability, maybe we may have a sysfs node at class input that would allow
the creation/removal of the filtered event interface.
No, if you want separate event devices just create a new instance of
input device for every keymap and have driver/irrcv class route events
to proper input device.
This don't solve the issue about how to signalize to kernel that more than one
input device is needed.
As the userspace will request the creation of those keymaps, we need some way
to receive such requests from userspace.
I can see a few ways for doing it:
1) create a control device for the irrcv device as a hole,
that would handle such requests via ioctl (/dev/irctl[0-9]* ?)
2) create a read/write sysfs node that would indicate the number of
event/keymaps
associated with a given IR. By writing a bigger number, it would create new
devices.
By writing a smaller number, it will delete some maps. There's an issue though:
what criteria would be used to delete? The newly created ones?
3) create a fixed number of event devices, and add a sysfs attribute to enable
or disable it;
4) create a fixed number of sysfs attributes to represent the keymaps. For
example:
/sys/class/irrcv/irrcv0/keymap0/enabled
...
/sys/class/irrcv/irrcv0/keymap7/enabled
The input/event node will be created only when the enabled=1.
I don't like (2) or (3), because removing a table with (2) may end by removing
the wrong
table, and (3) will create more event interfaces than probably needed by the
majority
of IR users.
maybe (4) is the better one.
--
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: [PULL] ov7670 changes
Jonathan Corbet wrote: On Fri, 26 Mar 2010 08:35:16 -0300 Mauro Carvalho Chehab mche...@infradead.org wrote: I'm now getting some warnings while compiling it with allyesconfig: Sigh...I don't really reserve all of my silly mistakes for you...it just must seem that way. Fix can be pulled from the same tree: git://git.lwn.net/linux-2.6.git ov7670 or can be found attached. Sorry for the noise. No problem. I probably only noticed it here because I do one compilation filtering the CC/LD/CHK messages from output - btw, an interesting patch would be to add add a even less verbose option to make compilation to show nothing but errors ;) Anyway, patch applied. 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: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Fri, Mar 26, 2010 at 02:22:51PM -0300, Mauro Carvalho Chehab wrote:
Dmitry Torokhov wrote:
On Fri, Mar 26, 2010 at 11:40:41AM -0300, Mauro Carvalho Chehab wrote:
David Härdeman wrote:
I'd suggest:
struct keycode_table_entry {
unsigned keycode;
unsigned index;
unsigned len;
char scancode[];
};
Use index in EVIOCGKEYCODEBIG to look up a keycode (all other fields are
ignored), that way no special function to clear the table is necessary,
instead you do a loop with:
EVIOCGKEYCODEBIG (with index 0)
EVIOCSKEYCODEBIG (with the returned struct from EVIOCGKEYCODEBIG and
keycode = KEY_RESERVED)
until EVIOCGKEYCODEBIG returns an error.
Makes sense.
Yes, I think so too. Just need a nice way to handle transition, I'd
like in the end to have drivers implement only the improved methods and
map legacy methods in evdev.
Ok. I'll prepare the patches for adding the new ioctl, in a way that it will
also handle the legacy methods, and post for review.
If EVIOCGKEYCODEBIG is going to be used as a superset of the old ioctl,
might it be a good idea change the proposed struct to:
struct keycode_table_entry {
unsigned keycode;
unsigned index;
unsigned type;
unsigned len;
char scancode[];
};
Where type is used to give a hint of how the scancode[] member should
be interpreted?
On a related note, I really think the interface would benefit from
allowing more than one keytable per irrcv device with an input
device created per keytable. That way you can have one input device
per remote control. This implies that EVIOCLEARKEYCODEBIG is a bit
misplaced as an evdev IOCTL since there's an N-1 mapping between
input devices and irrcv devices.
I don't think that an ioctl over one /dev/input/event should be the
proper way
to ask kernel to create another filtered /dev/input/event. As it
were commented
that the multimedia keys on some keyboards could benefit on having a
filter
capability, maybe we may have a sysfs node at class input that would
allow
the creation/removal of the filtered event interface.
No, if you want separate event devices just create a new instance
of
input device for every keymap and have driver/irrcv class route
events
to proper input device.
I fully agree!
This don't solve the issue about how to signalize to kernel that more than one
input device is needed.
As the userspace will request the creation of those keymaps, we need some way
to receive such requests from userspace.
I can see a few ways for doing it:
1) create a control device for the irrcv device as a hole,
that would handle such requests via ioctl (/dev/irctl[0-9]* ?)
2) create a read/write sysfs node that would indicate the number of
event/keymaps
associated with a given IR. By writing a bigger number, it would create new
devices.
By writing a smaller number, it will delete some maps. There's an issue
though:
what criteria would be used to delete? The newly created ones?
This won't work for the reason you've already set out...which keymap
should be deleted?
3) create a fixed number of event devices, and add a sysfs attribute to enable
or disable it;
You really seem to prefer sysfs over ioctls :)
4) create a fixed number of sysfs attributes to represent the keymaps. For
example:
/sys/class/irrcv/irrcv0/keymap0/enabled
...
/sys/class/irrcv/irrcv0/keymap7/enabled
The input/event node will be created only when the enabled=1.
This sounds like 3)
I don't like (2) or (3), because removing a table with (2) may end by
removing the wrong
table, and (3) will create more event interfaces than probably needed by the
majority
of IR users.
maybe (4) is the better one.
Personally I think 1) is the best approach. Having a device for the
irrcv device allows for three kinds of operations:
read
which corresponds to RX...you're eventually going to want to let
userspace devices read IR commands which have no entries in a keytable
yet in order to create keytables for new remotes, the same interface can
also be used for lirc-type user-space apps which want to access the raw
pulse/space timings for userspace decoding.
write
-
which would correspond to TX...I'd suggest a stream of s32 integers to
imply pulse/space timings.
ioctl
-
for controlling the RX/TX parameters, creating/destroying additional
keytables, etc...
Basically, we'll end up with a lirc_dev 2.0. And the irrcv class name
will be misleading since it will be irrcv + irsnd :)
--
David Härdeman
--
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] What are the goals for the architecture of an in-kernel IR system?
On Fri, Mar 26, 2010 at 12:17:34PM -0300, Mauro Carvalho Chehab wrote: David Härdeman wrote: On Thu, Mar 25, 2010 at 11:42:33AM -0300, Mauro Carvalho Chehab wrote: 2) add current_protocol support on other drivers; Done. Patch were already merged upstream. The current_protocol attribute shows the protocol(s) that the device is accepting and allows changing it to another protocol. In the case of the em28xx hardware, only one protocol can be active, since the decoder is inside the hardware. On the raw IR decode implementation I've done at the saa7134, all raw pulse events are sent to all registered decoders, so I'm thinking on using this sysfs node to allow disabling the standard behavior of passing the IR codes to all decoders, routing it to just one decoder. Another alternative would be to show current_protocol only for devices with hardware decoder, and create one sysfs node for each decoder, allowing enabling/disabling each decoder individually. You're eventually going to want to add ioctl's to set a lot of TX or RX parameters in one go (stuff like active receiver(s) and transmitter(s), carrier frequency, duty cycle, timeouts, filter levels and resolution - all of which would need to be set in one operation since some hardware will need to be reset after each parameter is changed). TX is a completely different history. It has nothing to do with input event subsystem. So, another approach should be taken for it. I suggest (though I might not have been clear on that point) that irrcv devices create a char node...ir specifics are handled via that node (with read/write/ioctl...see the other mail I just send). I haven't seen yet a hardware decoder with such parameters, but maybe I just don't have enough specs here to adjust them. The entire idea is to have a common API for hardware decoders and decoders which provide raw pulse/space timings. That, to me, is one of the major points of having in-kernel IR decoders - being able to provide a consistent interface for both hardware decoders and pulse/space hardware. Anyway, one simple way to avoid resetting the hardware for every new parameter change would be to use a timer for reset. This way, an userspace application or script that is touching on several parameters would just send the complete RX init sequence and after some dozens of milliseconds, the hardware will load the new parameters. And I do not think that sounds like a good interface. Then you'll end up with a few things being controlled via sysfs and some being controlled via ioctls. Maybe it's a good idea to have a bitmask of supported and enabled protocols in those ioctls instead? There's an interesting discussion about bitmasks x a list of enumerated values as a way to represent a bitmask into a series of values on sysfs, at http://lwn.net/Articles/378219/ (see A critical look at sysfs attribute values article there). Not really relevant...that's just the minor detail of how a sysfs file might be represented. That's said, I'm starting to think that the better is to have some differentiation there between hardware and software decoders. IMO, software decoders are better handled with an enabled attribute, per software decoder, inside each irrcv. I think we can create an interface which obscures the differences: Software decoders will export all in-kernel IR decoders in a bitmask in the supported_protocols sysfs file or ioctl struct member. Hardware decoders will export the hardware supported protocol(s) in the same file/member. In addition, a sysfs file or ioctl member for enabled_protocols will control either the enabled in-kernel IR decoders or hardware decoder(s). As should be quite obvious by now...I suggest ioctls (on a irrcv specific chardev) for controlling this :) -- David Härdeman -- 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: WARNINGS
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 Mar 26 19:00:27 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14527:1ef0265456c8 git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 8c69c6ed6c74c94fa7ad6fa24eda452e4b212d81 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-armv5: OK linux-2.6.34-rc1-armv5: OK linux-2.6.32.6-armv5-davinci: WARNINGS linux-2.6.33-armv5-davinci: WARNINGS linux-2.6.34-rc1-armv5-davinci: WARNINGS linux-2.6.32.6-armv5-ixp: WARNINGS linux-2.6.33-armv5-ixp: WARNINGS linux-2.6.34-rc1-armv5-ixp: WARNINGS linux-2.6.32.6-armv5-omap2: WARNINGS linux-2.6.33-armv5-omap2: WARNINGS linux-2.6.34-rc1-armv5-omap2: WARNINGS linux-2.6.22.19-i686: WARNINGS linux-2.6.23.17-i686: WARNINGS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.20-i686: WARNINGS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-rc1-i686: WARNINGS linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.34-rc1-m32r: OK linux-2.6.32.6-mips: WARNINGS linux-2.6.33-mips: WARNINGS linux-2.6.34-rc1-mips: WARNINGS linux-2.6.32.6-powerpc64: WARNINGS linux-2.6.33-powerpc64: WARNINGS linux-2.6.34-rc1-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.17-x86_64: WARNINGS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.20-x86_64: WARNINGS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-rc1-x86_64: WARNINGS linux-git-armv5: OK linux-git-armv5-davinci: OK linux-git-armv5-ixp: OK linux-git-armv5-omap2: OK linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS spec: ERRORS spec-git: OK sparse: ERRORS linux-2.6.16.62-i686: WARNINGS linux-2.6.17.14-i686: WARNINGS linux-2.6.18.8-i686: WARNINGS linux-2.6.19.7-i686: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.16.62-x86_64: WARNINGS linux-2.6.17.14-x86_64: WARNINGS linux-2.6.18.8-x86_64: WARNINGS linux-2.6.19.7-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS 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 V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- 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 6/6] Staging: cx25821: fix coding style issues in cx25821-video-upstream.c
From 69fbde2030f2a35c5289467a40f9828bf22fdc35 Mon Sep 17 00:00:00 2001
From: Olimpiu Pascariu olimpiu.pasca...@gmail.com
Date: Sat, 27 Mar 2010 00:05:31 +0200
Subject: [PATCH 6/6] Staging: cx25821: fix coding style issues in
cx25821-video-upstream.c
This is a patch to cx25821-video-upstream.c file that fixes up warnings and
errors found by the checkpatch.pl tool
Signed-off-by: Olimpiu Pascariu olimpiu.pasca...@gmail.com
---
drivers/staging/cx25821/cx25821-video-upstream.c | 121 +++--
1 files changed, 63 insertions(+), 58 deletions(-)
diff --git a/drivers/staging/cx25821/cx25821-video-upstream.c
b/drivers/staging/cx25821/cx25821-video-upstream.c
index 3d7dd3f..ce7d051 100644
--- a/drivers/staging/cx25821/cx25821-video-upstream.c
+++ b/drivers/staging/cx25821/cx25821-video-upstream.c
@@ -31,7 +31,7 @@
#include linux/syscalls.h
#include linux/file.h
#include linux/fcntl.h
-#include asm/uaccess.h
+#include linux/uaccess.h
MODULE_DESCRIPTION(v4l2 driver module for cx25821 based TV cards);
MODULE_AUTHOR(Hiep Huynh hiep.hu...@conexant.com);
@@ -59,9 +59,8 @@ int cx25821_sram_channel_setup_upstream(struct cx25821_dev
*dev,
cdt = ch-cdt;
lines = ch-fifo_size / bpl;
- if (lines 4) {
+ if (lines 4)
lines = 4;
- }
BUG_ON(lines 2);
@@ -96,7 +95,7 @@ int cx25821_sram_channel_setup_upstream(struct cx25821_dev
*dev,
}
static __le32 *cx25821_update_riscprogram(struct cx25821_dev *dev,
- __le32 * rp, unsigned int offset,
+ __le32 *rp, unsigned int offset,
unsigned int bpl, u32 sync_line,
unsigned int lines, int fifo_enable,
int field_type)
@@ -107,9 +106,8 @@ static __le32 *cx25821_update_riscprogram(struct
cx25821_dev *dev,
*(rp++) = cpu_to_le32(RISC_RESYNC | sync_line);
if (USE_RISC_NOOP_VIDEO) {
- for (i = 0; i NUM_NO_OPS; i++) {
+ for (i = 0; i NUM_NO_OPS; i++)
*(rp++) = cpu_to_le32(RISC_NOOP);
- }
}
/* scan lines */
@@ -139,14 +137,12 @@ static __le32 *cx25821_risc_field_upstream(struct
cx25821_dev *dev, __le32 * rp,
int dist_betwn_starts = bpl * 2;
/* sync instruction */
- if (sync_line != NO_SYNC_LINE) {
+ if (sync_line != NO_SYNC_LINE)
*(rp++) = cpu_to_le32(RISC_RESYNC | sync_line);
- }
if (USE_RISC_NOOP_VIDEO) {
- for (i = 0; i NUM_NO_OPS; i++) {
+ for (i = 0; i NUM_NO_OPS; i++)
*(rp++) = cpu_to_le32(RISC_NOOP);
- }
}
/* scan lines */
@@ -156,12 +152,13 @@ static __le32 *cx25821_risc_field_upstream(struct
cx25821_dev *dev, __le32 * rp,
*(rp++) = cpu_to_le32(0); /* bits 63-32 */
if ((lines = NTSC_FIELD_HEIGHT)
- || (line (NTSC_FIELD_HEIGHT - 1)) || !(dev-_isNTSC)) {
- offset += dist_betwn_starts;//to skip the other
field line
- }
+ || (line (NTSC_FIELD_HEIGHT - 1)) || !(dev-_isNTSC))
+ /* to skip the other field line */
+ offset += dist_betwn_starts;
- // check if we need to enable the FIFO after the first 4 lines
- // For the upstream video channel, the risc engine will enable
the FIFO.
+ /* check if we need to enable the FIFO after the first 4 lines
+* For the upstream video channel, the risc engine will enable
+* the FIFO. */
if (fifo_enable line == 3) {
*(rp++) = RISC_WRITECR;
*(rp++) = sram_ch-dma_ctl;
@@ -180,7 +177,8 @@ int cx25821_risc_buffer_upstream(struct cx25821_dev *dev,
{
__le32 *rp;
int fifo_enable = 0;
- int singlefield_lines = lines 1; //get line count for single
field
+ /* get line count for single field */
+ int singlefield_lines = lines 1;
int odd_num_lines = singlefield_lines;
int frame = 0;
int frame_size = 0;
@@ -224,7 +222,7 @@ int cx25821_risc_buffer_upstream(struct cx25821_dev *dev,
fifo_enable = FIFO_DISABLE;
- //Even Field
+ /* Even Field */
rp = cx25821_risc_field_upstream(dev, rp,
dev-_data_buf_phys_addr +
databuf_offset, bottom_offset,
@@ -240,7 +238,9 @@ int cx25821_risc_buffer_upstream(struct cx25821_dev *dev,
risc_flag = RISC_CNT_INC;
}
- // Loop to 2ndFrameRISC or to Start of Risc program generate
IRQ
+ /* Loop to 2ndFrameRISC or
Re: Avermedia AVerTV GO 007 FM composite input problem
Hi, Am Freitag, den 26.03.2010, 13:10 +0200 schrieb Andras Barna: hi i have a Avermedia AVerTV GO 007 FM card , the problem is that i get nothing from Composite, i tried different apps (mplayer, tvtime, etc) none works. (television input works) ideas? looking it up from 2005 to now, Composite was never reported as tested, only S-Video. On the other hand, vmux=0 is what we regularly see on combined S-Video and Composite inputs where you need an adapter for Composite over S-Video. The card has no separate Composite-in connector. Assuming you did not plug by mistake into the radio antenna input, then you can also try with vmux 3, 2 and 4 for Composite in saa7134-cards.c. You might have a look at the manual and/or windows driver, since this information is not provided to us until now. (bttv-gallery/wiki/lists) Does it come with any simple 4pin adapter or even with a breakout cable with more pins and a dedicated yellow RCA input? Cheers, Hermann here're some infos [9.361212] saa7130/34: v4l2 driver version 0.2.15 loaded [9.361631] alloc irq_desc for 17 on node -1 [9.361635] alloc kstat_irqs on node -1 [9.361648] saa7134 :00:09.0: PCI INT A - GSI 17 (level, low) - IRQ 17 [9.361768] saa7133[0]: found at :00:09.0, rev: 208, irq: 17, latency: 32, mmio: 0xcfffc800 [9.361955] saa7133[0]: subsystem: 1461:f31f, board: Avermedia AVerTV GO 007 FM [card=57,autodetected] [9.362198] saa7133[0]: board init: gpio is 8 [9.362424] input: saa7134 IR (Avermedia AVerTV GO as /devices/pci:00/:00:09.0/input/input6 [9.362713] IRQ 17/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs [9.501011] saa7133[0]: i2c eeprom 00: 61 14 1f f3 ff ff ff ff ff ff ff ff ff ff ff ff [9.501838] saa7133[0]: i2c eeprom 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.502592] saa7133[0]: i2c eeprom 20: ff d2 fe ff ff ff ff ff ff ff ff ff ff ff ff ff [9.503343] saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.504095] saa7133[0]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.504842] saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.505593] saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.506345] saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.507097] saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.507846] saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.508600] saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.509354] saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.510107] saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.510920] saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.511672] saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [9.512423] saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 10.780106] tuner 0-004b: chip found @ 0x96 (saa7133[0]) [ 10.815008] tda829x 0-004b: setting tuner address to 61 [ 11.349012] tda829x 0-004b: type set to tda8290+75 [ 14.869150] saa7133[0]: registered device video0 [v4l2] [ 14.869305] saa7133[0]: registered device vbi0 [ 14.869447] saa7133[0]: registered device radio0 [ 14.968864] saa7134 ALSA driver for DMA sound loaded [ 14.970728] IRQ 17/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs [ 14.970892] saa7133[0]/alsa: saa7133[0] at 0xcfffc800 irq 17 registered as card -1 [snip] -- 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 4/9] drivers/media: Fix continuation lines
Signed-off-by: Joe Perches j...@perches.com --- drivers/media/video/ov511.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/ov511.c b/drivers/media/video/ov511.c index e0bce8d..c34325c 100644 --- a/drivers/media/video/ov511.c +++ b/drivers/media/video/ov511.c @@ -57,8 +57,8 @@ #define DRIVER_VERSION v1.64 for Linux 2.5 #define EMAIL m...@alpha.dyndns.org #define DRIVER_AUTHOR Mark McClelland m...@alpha.dyndns.org Bret Wallach \ -Orion Sky Lawlor olaw...@acm.org Kevin Moore Charl P. Botha \ - cpbo...@ieee.org Claudio Matsuoka clau...@conectiva.com + Orion Sky Lawlor olaw...@acm.org Kevin Moore Charl P. Botha \ +cpbo...@ieee.org Claudio Matsuoka clau...@conectiva.com #define DRIVER_DESC ov511 USB Camera Driver #define OV511_I2C_RETRIES 3 -- 1.7.0.14.g7e948 -- 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
dmsg dump for Tevion High Speed DVD Maker
Hi, Was trying to get a firewire port working in Ubuntu 9.10 when I noticed that I had my USB Tevion DVD Maker plugged in and that you had a message requesting a copy of the dump for the unidentified DVD Maker. Attached is that dump as requested. Not sure where you are located but a German food store chain operating in the US under the name Aldi Food Stores has sold these a couple times that I know of. There are at least two versions although they function the same. A couple years ago they had them for $40 US. Last fall they had them for $20. At that price they should have been popular so should be other Linux users with them. Have seen a few users on the boards trying to get them going. They work well under Windows Vista but have never gotten one to work under Linux. Have been trying to get away from Windows for video work but have not been able to get either the this USB device or my Sony DSR-20 DV/DVCAM firewire deck to work under Linux. Am not all that good at Linux and any help you care to provide would be most welcome. Dave d...@systemax1:~$ dmesg [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 2.6.31-20-generic (bui...@palmer) (gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu8) ) #58-Ubuntu SMP Fri Mar 12 05:23:09 UTC 2010 (Ubuntu 2.6.31-20.58-generic) [0.00] KERNEL supported cpus: [0.00] Intel GenuineIntel [0.00] AMD AuthenticAMD [0.00] NSC Geode by NSC [0.00] Cyrix CyrixInstead [0.00] Centaur CentaurHauls [0.00] Transmeta GenuineTMx86 [0.00] Transmeta TransmetaCPU [0.00] UMC UMC UMC UMC [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009fc00 (usable) [0.00] BIOS-e820: 0009fc00 - 000a (reserved) [0.00] BIOS-e820: 000e - 0010 (reserved) [0.00] BIOS-e820: 0010 - bf6a (usable) [0.00] BIOS-e820: bf6a - bf6ae000 (ACPI data) [0.00] BIOS-e820: bf6ae000 - bf6f (ACPI NVS) [0.00] BIOS-e820: bf6f - bf6fe000 (reserved) [0.00] BIOS-e820: fee0 - fee01000 (reserved) [0.00] BIOS-e820: fff8 - 0001 (reserved) [0.00] DMI present. [0.00] AMI BIOS detected: BIOS may corrupt low RAM, working around it. [0.00] e820 update range: - 0001 (usable) == (reserved) [0.00] last_pfn = 0xbf6a0 max_arch_pfn = 0x10 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-CBFFF write-protect [0.00] CC000-D uncachable [0.00] E-E write-through [0.00] F-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 0 mask F8000 write-back [0.00] 1 base 08000 mask FC000 write-back [0.00] 2 base 0BF70 mask 0 uncachable [0.00] 3 base 0BF80 mask FFF80 uncachable [0.00] 4 disabled [0.00] 5 disabled [0.00] 6 disabled [0.00] 7 disabled [0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [0.00] Scanning 0 areas for low memory corruption [0.00] modified physical RAM map: [0.00] modified: - 0001 (reserved) [0.00] modified: 0001 - 0009fc00 (usable) [0.00] modified: 0009fc00 - 000a (reserved) [0.00] modified: 000e - 0010 (reserved) [0.00] modified: 0010 - bf6a (usable) [0.00] modified: bf6a - bf6ae000 (ACPI data) [0.00] modified: bf6ae000 - bf6f (ACPI NVS) [0.00] modified: bf6f - bf6fe000 (reserved) [0.00] modified: fee0 - fee01000 (reserved) [0.00] modified: fff8 - 0001 (reserved) [0.00] initial memory mapped : 0 - 00c0 [0.00] init_memory_mapping: -377fe000 [0.00] Using x86 segment limits to approximate NX protection [0.00] 00 - 40 page 4k [0.00] 40 - 003740 page 2M [0.00] 003740 - 00377fe000 page 4k [0.00] kernel direct mapping tables up to 377fe000 @ 1-15000 [0.00] RAMDISK: 378a5000 - 37fef6df [0.00] Allocated new RAMDISK: 008b2000 - 00ffc6df [0.00] Move RAMDISK from 378a5000 - 37fef6de to 008b2000 - 00ffc6de [0.00] ACPI: RSDP 000f9640 00014 (v00 ACPIAM) [0.00] ACPI: RSDT bf6a 00044 (v01
Re: dmsg dump for Tevion High Speed DVD Maker
Hi, Am Freitag, den 26.03.2010, 23:26 -0400 schrieb OurMail: Hi, Was trying to get a firewire port working in Ubuntu 9.10 when I noticed that I had my USB Tevion DVD Maker plugged in and that you had a message requesting a copy of the dump for the unidentified DVD Maker. Attached is that dump as requested. Not sure where you are located but a German food store chain operating in the US under the name Aldi Food Stores has sold these a couple times that I know of. There are at least two versions although they function the same. A couple years ago they had them for $40 US. Last fall they had them for $20. At that price they should have been popular so should be other Linux users with them. Have seen a few users on the boards trying to get them going. They work well under Windows Vista but have never gotten one to work under Linux. Have been trying to get away from Windows for video work but have not been able to get either the this USB device or my Sony DSR-20 DV/DVCAM firewire deck to work under Linux. Am not all that good at Linux and any help you care to provide would be most welcome. Dave just a hint. If Aldi stuff is called Medion as well, you usually find the device at http://www.creatix.de. If it is called Tevion, it can be some AverMedia Kworld or whatever clone. Cheers, Hermann einfaches Textdokument-Anlage (dmesg-dump-ourmailATkconlineDOTcom) d...@systemax1:~$ dmesg [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 2.6.31-20-generic (bui...@palmer) (gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu8) ) #58-Ubuntu SMP Fri Mar 12 05:23:09 UTC 2010 (Ubuntu 2.6.31-20.58-generic) [0.00] KERNEL supported cpus: [0.00] Intel GenuineIntel [0.00] AMD AuthenticAMD [0.00] NSC Geode by NSC [0.00] Cyrix CyrixInstead [0.00] Centaur CentaurHauls [0.00] Transmeta GenuineTMx86 [0.00] Transmeta TransmetaCPU [0.00] UMC UMC UMC UMC [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009fc00 (usable) [0.00] BIOS-e820: 0009fc00 - 000a (reserved) [0.00] BIOS-e820: 000e - 0010 (reserved) [0.00] BIOS-e820: 0010 - bf6a (usable) [0.00] BIOS-e820: bf6a - bf6ae000 (ACPI data) [0.00] BIOS-e820: bf6ae000 - bf6f (ACPI NVS) [0.00] BIOS-e820: bf6f - bf6fe000 (reserved) [0.00] BIOS-e820: fee0 - fee01000 (reserved) [0.00] BIOS-e820: fff8 - 0001 (reserved) [0.00] DMI present. [0.00] AMI BIOS detected: BIOS may corrupt low RAM, working around it. [0.00] e820 update range: - 0001 (usable) == (reserved) [0.00] last_pfn = 0xbf6a0 max_arch_pfn = 0x10 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-CBFFF write-protect [0.00] CC000-D uncachable [0.00] E-E write-through [0.00] F-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 0 mask F8000 write-back [0.00] 1 base 08000 mask FC000 write-back [0.00] 2 base 0BF70 mask 0 uncachable [0.00] 3 base 0BF80 mask FFF80 uncachable [0.00] 4 disabled [0.00] 5 disabled [0.00] 6 disabled [0.00] 7 disabled [0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [0.00] Scanning 0 areas for low memory corruption [0.00] modified physical RAM map: [0.00] modified: - 0001 (reserved) [0.00] modified: 0001 - 0009fc00 (usable) [0.00] modified: 0009fc00 - 000a (reserved) [0.00] modified: 000e - 0010 (reserved) [0.00] modified: 0010 - bf6a (usable) [0.00] modified: bf6a - bf6ae000 (ACPI data) [0.00] modified: bf6ae000 - bf6f (ACPI NVS) [0.00] modified: bf6f - bf6fe000 (reserved) [0.00] modified: fee0 - fee01000 (reserved) [0.00] modified: fff8 - 0001 (reserved) [0.00] initial memory mapped : 0 - 00c0 [0.00] init_memory_mapping: -377fe000 [0.00] Using x86 segment limits to approximate NX protection [0.00] 00 - 40 page 4k [0.00] 40 - 003740 page
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Hi! Anyway, one simple way to avoid resetting the hardware for every new parameter change would be to use a timer for reset. This way, an userspace application or script that is touching on several parameters would just send the complete RX init sequence and after some dozens of milliseconds, the hardware will load the new parameters. And I do not think that sounds like a good interface. Yep. Having artifical delay is ugly, racy and error prone. (If application is swapped out, you'll set the hardware to middle state, anyway). Better solution would be to have COMMIT command that actually does the setup, or interface that allows all parameters at once... -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
