Question about ci drivers in dvb
Dear all: I have read ci.txt under documents/dvb, and at end of it, it mentions about apdu protocol defined in en50221. but I cannot see this part of source in dvb_ca_en50221.c. Is this part implemented at other place or I check the wrong document? appreciate your help, miloody -- 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] Writing a new driver help please
Hi. Maybe this code will help. This driver registers new adapter, demux and frontend. It also registers char devices /dev/dvbstubi[0-9]. This devices should be used for writing raw TS stream. Stream will be processed by dvb-core internals. Module has one parameter - baudrate, to prevent overflows in DVR buffers. Thereare no PCI or USB dependencies, but code has some problems, see FIXMEs .. 2009/4/5 Marc Murphy marcm...@marcm.co.uk: Hi All, I'm new to DVB and attempting to write a driver to use on an embedded platform that I am developing. I have used the current micronas demod with a kernel driver that I wrote to enable my system to tune and stream live TS. However I thought it would be good to bring my driver up to the spec of DVB and need a few pointers. I have taken an example driver but they all seem to be working off either USB or PCI, my system uses neither. I have the standard i2c for microcode initialisation and control but the TS comes directly into my micro. Is there a simple way to write a basic driver that uses the standard DVB framework so that I can register a device without having to use PCI or USB ? What I have tried so far it to add an adaptor and then add a device. It seems to be working up to the point of the second call to sysfs to create the symbolic link to video0. I don't fully understand what is going on or whether there is anything I need to initialise before attempting to create the device but I can post code snippets if that would help. I hope somebody out there understands what I am going on about. Thanks Marc. ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- Sergey dvbstub1.tar.bz2 Description: BZip2 compressed data
Re: libv4l: Possibility of changing the current pixelformat on the fly
On 04/05/2009 06:53 PM, Theodore Kilgore wrote: On Sun, 5 Apr 2009, Hans de Goede wrote: On 04/05/2009 01:26 PM, Erik Andrén wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hans de Goede wrote: On 04/04/2009 10:22 PM, Erik Andrén wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, While trying to get hflip and vflip working for the stv06xx webcam bridge coupled to the vv6410 sensor I've come across the following problem. When flipping the image horizontally, vertically or both, the sensor pixel ordering changes. In the m5602 driver I was able to compensate for this in the bridge code. In the stv06xx I don't have this option. One way of solving this problem is by changing the pixelformat on the fly, i. e V4L2_PIX_FMT_SGRB8 is the normal format. When a vertical flip is required, change the format to V4L2_SBGGR8. My current understanding of libv4l is that it probes the pixelformat upon device open. In order for this to work we would need either poll the current pixelformat regularly or implement some kind of notification mechanism upon a flipping request. What do you think is this the right way to go or is there another alternative. The changing of the pixelformat only happens when you flip the data before conversion. If you look at the current upside down handling code you will see it does the rotate 180 degrees after conversion. This is how the vflip / hflip should be handled too. We only have 4 (2 really since we don't care about r versus b / u versus v while flippiing) destination formats for which we then need to write flipping code. Otherwise we need to write flipping code for *all* supported input formats, not to mention flipping some input formats is close to impossible (JPEG for example). So you mean we should do the vflip/hflip in software, just exposing one native format? Erm, yes that is what I was saying, but that is because I was confusing things with the sq905 driver some other people are working on. Now I understand what you were trying to ask. So the problem is that the vv6410 sensor can do flipping in hardware, and then the order in which it sends out the pixels changes from gbgbgb (for example) to bgbgbg, for the lines which have blue, effectively changing the pixelformat, right? You mention the sq905 cameras, and the general problem of image flipping. You comment that the order of the data changes if any kind of flipping is done, with the result that the image format (Bayer tiling) changes. One difference I do see here is that the vv6410 sensor can do flipping in hardware which the sq905 cameras obviously can not. However, the fact that the Bayer tiling of the image must change in accordance with the flipping is equally present. And I do not see how that problem could be avoided, on any occasion when flipping is needed. This brings up an interesting question of what would be the most efficient way actually to do the required image flipping: If the flipping is done before the finished image is produced, then the Bayer tiling of the image has changed. Therefore a different treatment is needed. If the flipping is done after the finished image is produced, then there is three times as much data, and the flipping might take longer (or might not if it were done exactly right?). True, still doing the flipping after the conversion is done, is what we are currently doing for the rotate 180 case (so h-flip + v-flip) and is what I think we should also do for the regular h-flip and v-flip. Why? Simplicity! We support 4 different destination formats, which can be simplified to 3 for the flipping case (we do not need to care about uv order). So that means writing vflip + hflip + rotate 180 = 3 x 3 9 flipping routines. At the moment we support 23 different source formats, so doing flipping at the level requires 3 x 23 = 69 flipping routines of which we can shave of quite a bit by being smart here and there, but then we are still left with quite a large number. But the most important reason for me not to want to do this at the source format level, is that I do not want to make it harder to add new source formats. Currently for a new source format, conversion routines for all 4 dest formats must be written, so that is 4 new conversion routines at worst. I do not want to make adding new formats harder. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Auto-response for your message to the linux-dvb mailing list
Dear Sirs Thanks for auto-reply response but sorry may be you will re-address, please, Pi-consults offer about possible collaboration in IT-outsourcing software development to relevant department that is responsible for RD or for business development within your entity or other business partners which are interesting in such outside software development service. I would be grateful to you for this help and assistance. So I look forward to hearing from you if you will be interested in the terms mentioned above. Thanks in advance. BR. Yours truly Viktor Shkel Chief Marketing Officer for pi-consult.by Tel: +49 (0) 721 20 12 51 951 ; +375 172 92 41 13 Mobile: +49 (0) 173 8000 751 ; +375 299 137 047 E-mail: sh...@pi-consult.by This ML is deprecated. Please use linux-media@vger.kernel.org instead. For more info about linux-media@vger.kernel.org, please read: http://vger.kernel.org/vger-lists.html#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: Auto-response for your message to the linux-dvb mailing list
Dear Sirs Thanks for auto-reply response but sorry may be you will re-address, please, Pi-consults offer about possible collaboration in IT-outsourcing software development to relevant department that is responsible for RD or for business development within your entity or other business partners which are interesting in such outside software development service. I would be grateful to you for this help and assistance. So I look forward to hearing from you if you will be interested in the terms mentioned above. Thanks in advance. BR. Yours truly Viktor Shkel Chief Marketing Officer for pi-consult.by Tel: +49 (0) 721 20 12 51 951 ; +375 172 92 41 13 Mobile: +49 (0) 173 8000 751 ; +375 299 137 047 E-mail: sh...@pi-consult.by This ML is deprecated. Please use linux-media@vger.kernel.org instead. For more info about linux-media@vger.kernel.org, please read: http://vger.kernel.org/vger-lists.html#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
v4l-dvb repository doesn't build
My latest pull of the v4l-dvb repository this morning broke the build: make[3]: *** No rule to make target `/home/khali/src/v4l-dvb/v4l/cx88-dsp.o', needed by `/home/khali/src/v4l-dvb/v4l/tda18271.o'. Stop. I am building against kernel 2.6.29.1. Yesterday it was building OK. I can't make any sense of this error. Help anyone? Thanks, -- Jean Delvare -- 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 3/6] ir-kbd-i2c: Switch to the new-style device binding model
On Sun, 05 Apr 2009 23:22:03 +0200, drunk and tired hermann pitton wrote: Hmm, I'm still happy with the broken DVB-T for saa7134 on 2.6.29, tasting some Chianti vine now and need to sleep soon, but I'm also not that confident that your saa7134 MSI t...@nywhere Plus i2c remote does work addressing it directly, since previous reports always said it becomes only visible at all after other devices are probed previously. Unfortunately I can't test it, but will try to reach some with such hardware and ask for testing, likely not on the list currently. Thanks for the heads up. I was curious about this as well. The original comment said that the MSI t...@nywhere Plus IR receiver would not respond to _probes_ before another device on the I2C bus was accessed. I didn't know for sure if this only applied to the probe sequence or to any attempt to access the IR receiver. As we no longer need to probe for the device, I thought it may be OK to remove the extra code. But probably the removal of the extra code should be delayed until we find one tester to confirm the exact behavior. Here, done. Anyone out there with a MSI t...@nywhere Plus that could help with testing? -- Jean Delvare -- 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: Test results for ir-kbd-i2c.c changes (Re: [PATCH 0/6] ir-kbd-i2c conversion to the new i2c binding model)
Hi Andy, On Sun, 05 Apr 2009 20:22:59 -0400, Andy Walls wrote: I tested your original patch set so you can get some real feedback. The news is good, but I'll bore you with the details first. :) 1. My setup: HVR-1600: Hauppauge model 74041, rev C5B2, serial# 891351 has no radio, has IR receiver, has IR transmitter (Zilog Z8F0811) Hauppauge Remote: Grey top side black bottom side; with 4 colored buttons Red, Green, Yellow, Blue; Numbers inside battery cover: A415-HPG M25909070211590 uname -a: Linux morgan.walls.org 2.6.27.9-73.fc9.x86_64 #1 SMP Tue Dec 16 14:54:03 EST 2008 x86_64 x86_64 x86_64 GNU/Linux v4l-dvb: pulled this morning. 2. OK, my first test had no effect, because I'm an idiot. :) In the cx18 driver, I didn't remove the I2C addresses in your original patch, and I didn't add 0x71 as a valid address. 3. My second test had bad results: # modprobe ir-kbd-i2c debug=3 hauppauge=1 Message from sysl...@morgan at Apr 5 18:47:14 ... kernel:Oops: 0010 [1] SMP Message from sysl...@morgan at Apr 5 18:47:14 ... kernel:Code: Bad RIP value. Message from sysl...@morgan at Apr 5 18:47:14 ... kernel:CR2: input: i2c IR (SAA713x remote) as /devices/virtual/input/input6 ir-kbd-i2c: i2c IR (SAA713x remote) detected at i2c-1/1-0071/ir0 [cx18 i2c driver #0-0] ir-kbd-i2c: ir_poll_key BUG: unable to handle kernel NULL pointer dereference at IP: [] 0x0 PGD 71c36067 PUD 2cca2067 PMD 0 Oops: 0010 [1] SMP CPU 0 Modules linked in: ir_kbd_i2c(+) ir_common mxl5005s s5h1409 tuner_simple tuner_types cs5345 tuner cx18 dvb_core cx2341x v4l2_common videodev v4l1_compat v4l2_compat_ioctl32 tveeprom i2c_algo_bit fuse ipt_REJECT nf_conntrack_ipv4 iptable_filter ip_tables ip6t_REJECT xt_tcpudp nf_conntrack_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables x_tables cpufreq_ondemand powernow_k8 freq_table loop dm_multipath scsi_dh ipv6 snd_hda_intel snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm i2c_piix4 snd_timer snd_page_alloc ppdev parport_pc snd_hwdep i2c_core shpchp parport pcspkr snd soundcore sr_mod r8169 mii k8temp hwmon cdrom sg floppy dm_snapshot dm_zero dm_mirror dm_log dm_mod pata_acpi ata_generic pata_atiixp libata sd_mod scsi_mod crc_t10dif ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd [last unloaded: tveeprom] Pid: 9, comm: events/0 Not tainted 2.6.27.9-73.fc9.x86_64 #1 RIP: 0010:[] [] 0x0 RSP: 0018:880077bede58 EFLAGS: 00010286 RAX: 001b RBX: 88005e73ee30 RCX: ccc6 RDX: a031ba00 RSI: a031ba04 RDI: 88005e73ec00 RBP: 880077bede80 R08: 880077bec000 R09: ccc6 R10: 0126a7e22b3d R11: 880073159bd8 R12: 88005e73ec00 R13: 0064 R14: a0318371 R15: 880077804908 FS: 7fa0409126f0() GS:814ad100() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b CR2: CR3: 569f6000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process events/0 (pid: 9, threadinfo 880077bec000, task 880077bbdb80) Stack: a03183df 880077bede80 88005e73ee38 880077804900 88005e73ee30 880077bedec0 8104fe45 880077bedec0 880077804900 880077804918 880077804908 880077beded0 Call Trace: [a03183df] ? ir_work+0x6e/0xd2 [ir_kbd_i2c] [8104fe45] run_workqueue+0xa3/0x146 [8104ffdd] worker_thread+0xf5/0x109 [81053741] ? autoremove_wake_function+0x0/0x38 [8104fee8] ? worker_thread+0x0/0x109 [810533d7] kthread+0x49/0x76 [810116e9] child_rip+0xa/0x11 [81010a07] ? restore_args+0x0/0x30 [8105338e] ? kthread+0x0/0x76 [810116df] ? child_rip+0x0/0x11 Code: Bad RIP value. RIP [] 0x0 RSP 880077bede58 CR2: ---[ end trace 6076b08e85151d70 ]--- That's because in ir-kbd-i2c.c:ir_poll_key(), ir-get_key() was a NULL function pointer. I realized that ir-kbd-i2c.c:ir_probe() would need a fix-up for address 0x71 for cx18 (and ivtv) or I would need to set the parameters via struct IR_i2c_init_data. There's a usable get_key function for Hauppauge remotes in ir-kbd-i2c, but no way via struct IR_i2c_init_data to specify that one wants to use it from the bridge driver. Nor is there a way to set the RC5 ir_type from the bridge driver. So mucking with ir-kbd-i2c.c for address 0x71 is what I did next. Yeah, ir-kbd-i2c is messy, setup for some boards is done in the ir-kbd-i2c driver itself and for some other boards it is done in the bridge driver. I presume that the idea was to avoid code duplication on one hand and bloating
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
Hi Andy,
On Sun, 05 Apr 2009 15:35:52 -0400, Andy Walls wrote:
--- v4l-dvb.orig/linux/drivers/media/video/ivtv/ivtv-i2c.c2009-04-04
10:53:08.0 +0200
+++ v4l-dvb/linux/drivers/media/video/ivtv/ivtv-i2c.c 2009-04-04
10:58:36.0 +0200
[snip]
-
+ const unsigned short addr_list[] = {
+ 0x1a, 0x18, 0x64, 0x30,
+ I2C_CLIENT_END
+ };
[snip]
I just noticed you're missing address 0x71 for ivtv. At least some
PVR-150 boards have a Zilog chip at that address.
Thanks for reporting. The list above is taken directly from the
original ir-kbd-i2c driver (minus address 0x4b which Hans Verkuil told
me was useless for the ivtv and cx18 adapters). I'm all for adding
support for more boards, however I'd rather do this _after_ the i2c
model conversion is done, so that we have a proper changelog entry
saying that we added support for the PVR-150, and that it gets proper
testing. Hiding support addition in a larger patch would probably do
as much harm as good.
--
Jean Delvare
--
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 Mike, I'll answer all your questions and express my concerns in this reply, to avoid spreading the info all around the discussion thread. On Mon, 6 Apr 2009 00:19:23 -0500 (CDT), Mike Isely wrote: Please pull from http://linuxtv.org/hg/~mcisely/pvrusb2 for two pvrusb2 changesets. One sets up the ability to track what kind of IR receiver is expected, Looks very good. The more we know about each board, the less probing we have to do, the better. the other optionally autoloads ir-kbd-i2c based on that result and a module option that can be used to disable that autoloading. Again, ir-kbd-i2c does _not_ auto-load. What my code (and now yours) does is instantiating an i2c device named ir-kbd. _If_ the ir-kbd-i2c driver is later loaded, it will bind to that device. We might let udev load the ir-kbd-i2c driver at some point in the future, but clearly we need to sort out the lirc case beforehand, otherwise some users will hit the problems you have anticipated, and we don't want this to happen. So, your module parameter is improperly named. Setting it to 1 does prevent the pvrusb2 driver from instantiating the ir-kbd device, and that's all. Speaking of this module parameter, I was a little worried at first that you wanted an inverted logic for it in pvrusb2 compared to what some other bridge drivers (saa7134, em28xx, cx231xx), but thinking a bit more about I came to the conclusion that it was OK because it matched the history of the pvrusb2 driver. Now I see that you followed their logic (enabled is the default) but you use a different module parameter name (disable_autoload_ir_kbd vs. disable_ir). I think there would be some value in sticking to a common name in all bridge drivers (like we have the standard video_nr module parameter.) That being said, I will not insist on this. My feeling is that this is all temporary anyway, because the removal of the legacy i2c model will break lirc and the main point is to decide how we will fix it. I'll post a separate summary with proposals. Depending on what we do, the module parameter you added is likely to become obsolete. This is the result of what I had posted about an hour ago. It looks like a lot of lines, but it was all basically trivial stuff. Note that these changes are safe; nothing is regressed here and this does not depend on anyone else's changes. Even though that second changeset won't really do much until Jean's ir-kbd-i2c stuff is merged, the fact is that it won't cause any harm either. Since the pvrusb2 driver wasn't previously autoloading ir-kbd-i2c anyway, this change therefore breaks nothing. For completeness, your second patch actually breaks the ir-kbd-i2c use case. Your code will instantiate a new-style ir-kbd device which the legacy ir-kbd-i2c can't use. As the instantiated device makes the address busy, the probing logic of legacy ir-kbd-i2c driver will skip it. Without my changes, all users will have to pass disable_autoload_ir_kbd=1, whether they want to use lirc or ir-kbd-i2c, otherwise they lose IR support. But honestly that doesn't matter much, I think, because the idea is to merge my changes quickly. But it does have the desirable effect in that it should take me out of the IR debate for now and I can stop being a pain to Jean :-) I am totally fine removing the pvrusb2 parts from my patch set, and letting you deal with it. As you know, my main concern here is to get rid of the legacy i2c model. So I am virtually happy with any solution that leads there, and I am gladly accepting all the help I can get to go there. Jean: I hope I didn't break any etiquette here. Though that second change is from me, the majority of the changeset really is from your patch to the pvrusb2 driver. I made changes to it so I didn't feel right in still trying to blame you for it ;-) Plus, if I were to hand it back to you for inclusion in your patch series then you would be dependant upon the pvrusb2 change I made to drive the decision about loading based on the device hardware. Since this change as a whole is mergeable without the rest of your changeset I felt it most expedient just to push this up now. That's alright. In this specific case I really don't care who gets the fame and flames, as longs as things get done quickly. Thank you for jumping in and helping me sorting it all out, this is very appreciated. -- Jean Delvare -- 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: tm6010 development repository
Mauro Carvalho Chehab wrote: On Sun, 05 Apr 2009 12:45:56 +1200 Kevin Wells wells_ke...@yahoo.co.nz wrote: Steven Toth wrote: Kevin Wells wrote: I've started trying to understand the code in the following repository: http://www.linuxtv.org/hg/~mchehab/tm6010/ I have a few patches I would like to apply. How should I do this? Submit the patches to the list and I'll try to get some time to create and maintain a ~stoth/tm6010 tree. I think I can get the nova-s-usb2 running with just a little effort. Patches to follow. Nothing exciting. Just trying to make the code more robust. Patches are very granular. Let me know if that doesn't work for you. I'll merge those with some patches I have here. hvr-900h analog part is working with a some troubles on the experimental tree I have here. A good thing to do, after I merge yours and my patches, is to convert it to the new v4l2 dev/subdev interface. I suspect that this will solve several bugs we currently have with the i2c interface of this driver. I intend to do this later this week, after the end of the merge window. For now, I still have lots of patches to review, in order to submit for 2.6.30. Thanks 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 3/6] ir-kbd-i2c: Switch to the new-style device binding model
On Sun, 5 Apr 2009 22:35:25 -0700 (PDT)
Uri Shkolnik uri...@yahoo.com wrote:
--- On Mon, 4/6/09, Mauro Carvalho Chehab mche...@infradead.org wrote:
From: Mauro Carvalho Chehab mche...@infradead.org
Subject: Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding
model
To: Andy Walls awa...@radix.net
Cc: hermann pitton hermann-pit...@arcor.de, Jean Delvare
kh...@linux-fr.org, Janne Grunau j...@jannau.net, Hans Verkuil
hverk...@xs4all.nl, Mike Isely is...@pobox.com, is...@isely.net,
LMML linux-media@vger.kernel.org, Jarod Wilson ja...@redhat.com
Date: Monday, April 6, 2009, 4:51 AM
On Sun, 05 Apr 2009 18:00:04 -0400
Andy Walls awa...@radix.net
wrote:
On Sun, 2009-04-05 at 23:22 +0200, hermann pitton
wrote:
Am Sonntag, den 05.04.2009, 22:22 +0200 schrieb
Jean Delvare:
On Sun, 05 Apr 2009 14:58:17 -0400, Andy
Walls wrote:
What can not be translated to the input system I
would like to know.
Andy seems to have closer looked into that.
1. IR blasting: sending IR codes to transmit out to a
cable convertor
box, DTV to analog convertor box, or similar devices
to change channels
before recording starts. An input interface
doesn't work well for
output.
On my understanding, IR output is a separate issue. AFAIK,
only a very few ivtv
devices support IR output. I'm not sure how this is
currently implemented.
2. Sending raw IR samples to user space: user space
applications can
then decode or match an unknown or non-standard IR
remote protocol in
user space software. Timing information to go
along with the sample
data probably needs to be
preserved. I'm assuming the input
interface
currently doesn't support that.
If the driver processes correctly the IR samples, I don't
see why you would
need to pass the raw protocols to userspace. Maybe we need
to add some ioctls
at the API to allow certain controls, like, for example,
ask kernel to decode
IR using RC4 instead or RC5, on devices that supports more
than one IR protocol.
That's all the Gerd mentioned.
One more nice feature to have, that I'm not sure how
easily the input
system could support:
3. specifying remote control code to key/button
translations with a
configuration file instead of recompiling a module.
The input and the current drivers that use input already
supports this feature.
You just need to load a new code table to replace the
existing one.
See v4l2-apps/util/keytable.c to see how easy is to change
a key code. It
contains a complete code to fully replace a key code table.
Also, the Makefile
there will extract the current keytables for the in-kernel
drivers.
Btw, with only 12 lines, you can create a keycode replace
hello world!:
#include fcntl.h
/* due to O_RDONLY */
#include stdio.h
/* open() */
#include linux/input.h /* input
ioctls and keycode macros */
#include sys/ioctl.h
/* ioctl() */
void main(void)
{
int codes[2];
int fd = open(/dev/video0,
O_RDONLY); /* Hmm.. in real apps, we
should check for errors */
codes[0] = 10;
/*
Scan code */
codes[1] = KEY_UP;
/* Key code */
ioctl(fd, EVIOCSKEYCODE,
codes); /* hello world! */
}
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
Hi,
ir-kbd-i2c is a confusing name and wrong architecture if all are truly
combined together.
Why to combine interface driver (I2C) with logical implementation (RC5
samples to input device codes)?
There are many IR hardware devices which are not I2C based. Lately I added a
patch (http://patchwork.kernel.org/patch/16406/) which uses such IR device.
There should be a complete separation between I2C interface driver with RC5
(and/or RCMM) data output, to the ir-kbd (RC5/kbd, RCMM/kbd) module, which
should only convert RC5 sample to system events (either input
device/keyboard, or IOCTL events sent through the DVB characters devices to
user space).
If the code will stay combined (ir-kbd-i2c) than for other than I2C interface
drivers, we'll have to add a duplicated (redundant) logical layer to handle
the RC5 to system events layer (which already exist at the ir-kbd-i2c).
This module is just for i2c devices. Non-i2c devices are handled together with
bridge drivers. Common routines like RC5 and pulse distande decoding are at
ir-functions.c, as part of ir-common.
There's no RC5 decoding functions there. What it has is some get_key routines
that gets the data from the i2c packet and properly fills the event fields.
It should be noticed that ir-kbd-i2c is that people never cared to create one
ir-i2c-foo module for each
Re: Test results for ir-kbd-i2c.c changes (Re: [PATCH 0/6] ir-kbd-i2c conversion to the new i2c binding model)
Hi Andy, On Mon, 06 Apr 2009 07:56:22 -0400, Andy Walls wrote: On Mon, 2009-04-06 at 10:54 +0200, Jean Delvare wrote: Thanks a lot for the testing! You're welcome. Sorry for being such a pain to what I suspect you hoped was to be a simple change. You must be kidding. For one thing, I never expected it to be a simple change ;) For another, you're helping me a lot with your comments and testing. Thanks! -- Jean Delvare -- 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 0/3] V4L2 driver for OMAP2/3 with new CIDs.
Hi All, -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Friday, March 20, 2009 12:56 PM To: Shah, Hardik Cc: linux-media@vger.kernel.org; linux-o...@vger.kernel.org Subject: Re: [PATCH 0/3] V4L2 driver for OMAP2/3 with new CIDs. On Friday 20 March 2009 06:18:44 Shah, Hardik wrote: Hi All, I will be posting series of three patches for the V4L2 driver on the OMAP2/3 DSS. Thanks! I'll review this within the week. [Shah, Hardik] I have fixed most of the comments and re-posting the patches. Regards, Hans Patch 1 - This is the second revision of the patch. Documentation added for the following new CIDs and bit fields added in V4L2 framework. V4L2_CID_BG_COLOR: Added new CID for setting of the back ground color on the output device. V4L2_CID_ROTATION: Added new CID for setting up of the rotation on the device. Both of the above ioctls are discussed in detail. V4L2_FBUF_FLAG_SRC_CHROMAKEY: Added the flags bit field to the flags field of the v4l2_framebuffer structure for supporting the source chroma keying. It's exactly opposite of the chroma keying supported with the flag V4L2_FBUF_FLAG_CHROMAKEY. V4L2_FBUF_CAP_SRC_CHROMAKEY: Added the capability bit field for the capability field of the v4l2_framebuffer structure. Documentation change related to the new bit field for the source chroma keying is new from the previous version. Patch 2 - Added New Control IDs for OMAP class of Devices as discussed above. This is the third revision of the patch of adding the new control IDs and bit fields. V4L2_FBUF_CAP_SRC_CHROMAKEY and V4L2_FBUF_FLAG_SRC_CHROMAKEY are newly added compared to previous revision of patch. New Ioctl for programming the color space conversion matrix is dropped from this patch as the accompanying driver with this patch is not still having implementation for the same. Related documentation is also removed. I will submit a separate patch for that with the necessary changes in driver to support the programming of the color space conversion. Some changes are required in DSS2 library also for doing the same. Patch 3 - This is a review patch since the DSS2 library is still to be accepted in community This is the third revision of the patch. This patch contains the V4L2 driver on the OMAP3 DSS2 using all of the above newly implemented CIDS and bit fields. Following are the changes in the driver compared to the previous version. 1. Added the chroma keying support. 2. Added alpha blending support. 3. Minor community comment fixed. 4. Ported to work with Tomi's latest DSS2 library with minor modification in DSS2 library. Path to Tomi's DSS2 library is http://www.bat.org/~tomba/git/linux-omap-dss.git/ commit id bc6dc4c7fabb8ba3bfe637a6c5dc271595a1bef6 All the comments and inputs are welcomed. Thanks and Regards Hardik Shah -- 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
RE: [PATCH 3/3] V4L2 Driver for OMAP3/3 DSS.
Hi Hans,
Please find my comments inline. Most of the comments are taken care of.
Regards,
Hardik Shah
static struct twl4030_hsmmc_info mmc[] __initdata = {
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 19cf3b8..91e4529 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -711,6 +711,26 @@ config VIDEO_CAFE_CCIC
CMOS camera controller. This is the controller found on first-
generation OLPC systems.
+#config VIDEO_OMAP3
+#tristate OMAP 3 Camera support
+# select VIDEOBUF_GEN
+# select VIDEOBUF_DMA_SG
+# depends on VIDEO_V4L2 ARCH_OMAP34XX
+# ---help---
+#Driver for an OMAP 3 camera controller.
Why add a commented config?
[Shah, Hardik] To make explicit that camera and display will have same config.
But any way removed and put a comment in config option.
+
+config VID1_LCD_MANAGER
+bool Use LCD Managaer
+help
+ Select this option if you want VID1 pipeline on LCD Overlay
manager
+endchoice
+
+choice
+ prompt VID2 Overlay manager
+ depends on VIDEO_OMAP_VIDEOOUT
+ default VID2_LCD_MANAGER
+
+config VID2_TV_MANAGER
+ bool Use TV Manager
+ help
+ Select this option if you want VID2 pipeline on TV Overlay manager
+
+config VID2_LCD_MANAGER
+ bool Use LCD Managaer
+ help
+ Select this option if you want VID2 pipeline on LCD Overlay manager
+endchoice
+
+choice
+prompt TV Mode
+depends on VID2_TV_MANAGER || VID1_TV_MANAGER
+default NTSC_M
+
+config NTSC_M
+bool Use NTSC_M mode
+help
+ Select this option if you want NTSC_M mode on TV
+
+config PAL_BDGHI
+bool Use PAL_BDGHI mode
+help
+ Select this option if you want PAL_BDGHI mode on TV
Why are these config options? Isn't it possible to do this dynamically
through VIDIOC_S_STD?
[Shah, Hardik] Currently is not tested/supported dynamically. I will add it at
todos.
+
+static u32 video1_numbuffers = 3;
+static u32 video2_numbuffers = 3;
+static u32 video1_bufsize = OMAP_VOUT_MAX_BUF_SIZE;
+static u32 video2_bufsize = OMAP_VOUT_MAX_BUF_SIZE;
+module_param(video1_numbuffers, uint, S_IRUGO);
+module_param(video2_numbuffers, uint, S_IRUGO);
+module_param(video1_bufsize, uint, S_IRUGO);
+module_param(video2_bufsize, uint, S_IRUGO);
I recommend adding MODULE_PARM_DESC() as well to provide a description of
these module options.
[Shah, Hardik] Added MODULE_PARM_DESC
+
+static int omap_vout_create_video_devices(struct platform_device *pdev);
+static int omapvid_apply_changes(struct omap_vout_device *vout, u32 addr,
+ int init);
+static int omapvid_setup_overlay(struct omap_vout_device *vout,
+ struct omap_overlay *ovl, int posx, int posy,
+ int outw, int outh, u32 addr, int tv_field1_offset, int init);
+static enum omap_color_mode video_mode_to_dss_mode(struct omap_vout_device
+ *vout);
+static void omap_vout_isr(void *arg, unsigned int irqstatus);
+static void omap_vout_cleanup_device(struct omap_vout_device *vout);
+/* module parameters */
^^ This comment should be moved up.
[Shah, Hardik] Done
+static int omap_vout_try_format(struct v4l2_pix_format *pix,
+ struct v4l2_pix_format *def_pix)
+{
+ int ifmt, bpp = 0;
+
+ if (pix-width VID_MAX_WIDTH)
+ pix-width = VID_MAX_WIDTH;
+ if (pix-height VID_MAX_HEIGHT)
+ pix-height = VID_MAX_HEIGHT;
+
+ if (pix-width = VID_MIN_WIDTH)
+ pix-width = def_pix-width;
+ if (pix-height = VID_MIN_HEIGHT)
+ pix-height = def_pix-height;
Linux provides some nice clamp macros for this. See linux/kernel.h.
[Shah, Hardik] I tried using it but still if condition is required as I have
four values to select from so I reverted back to same old method.
The else below should be indented one tab to the left.
+ } else {
+ dmabuf = videobuf_to_dma(q-bufs[vb-i]);
+
+ vout-queued_buf_addr[vb-i] = (u8 *) dmabuf-bus_addr;
+ }
Note this it is better to handle the else part first and return.
Then the large if-part can be handled after that and can be indented
on tab to the left as well.
I.e.:
if (cond) {
// lots of code
} else {
// small amount of code
}
can be rewritten as:
if (!cond) {
// small amount of code
return 0;
}
// lots of code.
+ return 0;
[Shah, Hardik] Done, Implemented
+}
+ /* get the display device attached to the overlay */
+ if (!ovl-manager || !ovl-manager-display)
+ return -1;
+ cur_display = ovl-manager-display;
+
+ if ((cur_display-type == OMAP_DISPLAY_TYPE_VENC)
+ ((win-w.width == crop-width)
+ (win-w.height == crop-height)))
+
RE: [PATCH 2/3] New V4L2 CIDs for OMAP class of Devices.
Hi Hans,
Please find my comments inline.
Regards,
Hardik Shah
-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Monday, March 30, 2009 5:29 PM
To: Shah, Hardik
Cc: linux-media@vger.kernel.org; linux-o...@vger.kernel.org; Jadav, Brijesh R;
Hiremath, Vaibhav
Subject: Re: [PATCH 2/3] New V4L2 CIDs for OMAP class of Devices.
On Friday 20 March 2009 06:19:57 Hardik Shah wrote:
Added V4L2_CID_BG_COLOR for background color setting.
Added V4L2_CID_ROTATION for rotation setting.
Above two ioclts are indepth discussed. Posting
again with the driver usage.
---
linux/drivers/media/video/v4l2-common.c |7 +++
linux/include/linux/videodev2.h |6 +-
2 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/linux/drivers/media/video/v4l2-common.c
b/linux/drivers/media/video/v4l2-common.c
index 3c42316..fa408f0 100644
--- a/linux/drivers/media/video/v4l2-common.c
+++ b/linux/drivers/media/video/v4l2-common.c
@@ -422,6 +422,8 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_CHROMA_AGC: return Chroma AGC;
case V4L2_CID_COLOR_KILLER: return Color Killer;
case V4L2_CID_COLORFX: return Color Effects;
+ case V4L2_CID_ROTATION: return Rotation;
I'm having second thoughts about this name. I think V4L2_CID_ROTATE is better,
since it is an action ('you rotate an image') rather than a status ('what is
the rotation of an image').
What do you think?
[Shah, Hardik] Yes, it should be V4L2_CID_ROTATE as V4L2_CID_HFLIP.
+ case V4L2_CID_BG_COLOR: return Background color;
/* MPEG controls */
case V4L2_CID_MPEG_CLASS: return MPEG Encoder Controls;
@@ -547,6 +549,10 @@ int v4l2_ctrl_query_fill(struct v4l2_queryctrl *qctrl,
s32 min, s32 max, s32 ste
qctrl-flags |= V4L2_CTRL_FLAG_READ_ONLY;
min = max = step = def = 0;
break;
+ case V4L2_CID_BG_COLOR:
+qctrl-type = V4L2_CTRL_TYPE_INTEGER;
+step = 1;
+break;
Set the min to 0 and max to 0xff.
[Shah, Hardik] Added
default:
qctrl-type = V4L2_CTRL_TYPE_INTEGER;
break;
@@ -571,6 +577,7 @@ int v4l2_ctrl_query_fill(struct v4l2_queryctrl *qctrl,
s32 min, s32 max, s32 ste
case V4L2_CID_BLUE_BALANCE:
case V4L2_CID_GAMMA:
case V4L2_CID_SHARPNESS:
+ case V4L2_CID_BG_COLOR:
This definitely isn't a slider control.
[Shah, Hardik] Removed
--
1.5.6
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 1/3] Documentation for new V4L2 CIDs added.
Hi Hans, Please find my comments inline. Regards, Hardik -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Monday, March 30, 2009 5:23 PM To: Shah, Hardik Cc: linux-media@vger.kernel.org; linux-o...@vger.kernel.org; Jadav, Brijesh R; Hiremath, Vaibhav Subject: Re: [PATCH 1/3] Documentation for new V4L2 CIDs added. Hi Hardik, OK, so it took a little longer than a week. So sue me :-) Typo: chorma - chroma [Shah, Hardik] Done in next post +images will be replaced by the video images. Exactly +opposite of constantV4L2_FBUF_CAP_CHROMAKEY/constant/entry Hmm. This is a bit obscure. CAP_CHROMAKEY means that framebuffer pixels with the chromakey color are replaced by video pixels. CAP_SRC_CHROMAKEY means that video pixels with the chromakey color are replaced by the framebuffer pixels. At least the way I read it this is the opposite of what you wrote. It pays to be very precise here since it can get confusing very quickly. [Shah, Hardik] Done in next post + /row /tbody /tgroup /table @@ -411,6 +418,18 @@ images, but with an inverted alpha value. The blend function is: output = framebuffer pixel * (1 - alpha) + video pixel * alpha. The actual alpha depth depends on the framebuffer pixel format./entry /row + row + entryconstantV4L2_FBUF_FLAG_SRC_CHROMAKEY/constant/entry + entry0x0040/entry + entryUse chroma-keying. The chroma-key color is Write: 'Use source chroma-keying.' to prevent confusion with V4L2_FBUF_FLAG_CHROMAKEY. [Shah, Hardik] Done in next post +determined by the structfieldchromakey/structfield field of +v4l2-window; and negotiated with the VIDIOC-S-FMT; ioctl, see xref +linkend=overlay and xref linkend=osd. +Since any one of the chorma keying can be active at a time as both Typo: chorma - chroma [Shah, Hardik] Done in next post +of them are exactly opposite same structfieldchromakey/structfield Typo: 'opposite same' - 'opposite the same' [Shah, Hardik] Done in next post +field of v4l2-window; can be used to set the chroma key for source +keying also./entry + /row /tbody /tgroup /table -- 1.5.6 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
[PATCH] Enabling of the Winfast TV2000 XP Global TV capture card remote control
From: Pieter C van Schaik vanste...@gmail.com The Winfast TV2000 XP Global video capture card IR remote keys were not initialized and handled in cx88-input.c; added two corresponding case statements, where this card's remote works exactly the same as the DTV1000's. Signed-off-by: Pieter C van Schaik vanste...@gmail.com --- --- linux-2.6.29/drivers/media/video/cx88/cx88-input.c.orig 2009-04-01 12:38:34.0 +0200 +++ linux-2.6.29/drivers/media/video/cx88/cx88-input.c 2009-04-01 12:39:07.0 +0200 @@ -92,6 +92,7 @@ static void cx88_ir_handle_key(struct cx gpio=(gpio 0x7fd) + (auxgpio 0xef); break; case CX88_BOARD_WINFAST_DTV1000: + case CX88_BOARD_WINFAST_TV2000_XP_GLOBAL: gpio = (gpio 0x6ff) | ((cx_read(MO_GP1_IO) 8) 0x900); auxgpio = gpio; break; @@ -239,6 +240,7 @@ int cx88_ir_init(struct cx88_core *core, break; case CX88_BOARD_WINFAST2000XP_EXPERT: case CX88_BOARD_WINFAST_DTV1000: + case CX88_BOARD_WINFAST_TV2000_XP_GLOBAL: ir_codes = ir_codes_winfast; ir-gpio_addr = MO_GP0_IO; ir-mask_keycode = 0x8f8; -- 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: Test results for ir-kbd-i2c.c changes (Re: [PATCH 0/6] ir-kbd-i2c conversion to the new i2c binding model)
On Mon, 2009-04-06 at 10:54 +0200, Jean Delvare wrote: Hi Andy, Note that struct IR_i2c_init_data only contains the fields I needed at the moment, but it would be trivial to extend it to allow bridge drivers to pass more setup information if needed, for example ir_type. Yeah, I could have mucked with it myself, but communicating back the whole merged diff would have been a hassle. I was just testing anyway. Success. OK, good to know that adding support for the cx18 will be possible and easy. I propose that we postpone this addition until after my code is merged though, to avoid making the situation more complex than it already is. Yeah. So far one user has asked for it. Thanks a lot for the testing! You're welcome. Sorry for being such a pain to what I suspect you hoped was to be a simple change. 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: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
On Mon, 2009-04-06 at 11:04 +0200, Jean Delvare wrote: Hi Andy, I'm all for adding support for more boards, however I'd rather do this _after_ the i2c model conversion is done, so that we have a proper changelog entry saying that we added support for the PVR-150, and that it gets proper testing. Hiding support addition in a larger patch would probably do as much harm as good. Makes sens to me. Especially when I just simply, blindly added 0x71 in my initial testing, I got a kernel Oops. 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: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
On Sun, 5 Apr 2009 13:48:02 -0500 (CDT) Mike Isely is...@isely.net wrote: My impression (at least for pvrusb2-driven devices) is that the later IR receivers require a completely different driver to work properly; one can't just bolt additional features into ir-kbd-i2c for this. This is the old approach: adding more stuff into ir-kbd-i2c. The new approach is to let ir-kbd-i2c to prepare for IR, but filling the protocol decoding routines and IR names after having it bound on i2c bus. So, the IR routines will be properly filled by the bridge driver (pvrusb2, in this case). In lirc's case, a different driver is in fact used. But you know this already. I haven't looked at ir-kbd-i2c in a while, but one other thing I seriously did not like about it was that the mapping of IR codes to key events was effectively hardcoded in the driver. That makes it difficult to make the same driver work with different kinds of remotes. Even if the bridge driver (e.g. pvrusb2) were to supply such a map, that's still wrong because it's within the realm of possibility that the user might actually want to use a different remote transmitter (provided it is compatible enough to work with the receiver hardware). The hardcoded keytables are just the default ones for that keyboard. As I've shown already in this thread, it can be easily replaced on userspace, and we have already an userspace tool on v4l2-apps that replaces those tables. The lirc architecture solves this easily via a conf file in userspace. In fact, lirc can map multiple mappings to a single receiver, permitting it to work concurrently with more than one remote. But is such a thing even possible with ir-kbd-i2c? I know this is one reason people tend to choose lirc. Multiple mappings based on what userspace app you're using can't be done internally. However, you can keep using lirc with event driver for those cases where you want to have multiple mappings, and this works fine. The only drawback i saw when I used lirc the last time (a long time ago) is that, when you remove an usb device, it used to flood the logs with errors (several errors by second, warning that event interface disappeared). Probably they already solved this issue. 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 3/6] ir-kbd-i2c: Switch to the new-style device binding model
On Sun, 5 Apr 2009 21:52:31 -0500 (CDT)
Mike Isely is...@isely.net wrote:
On Sun, 5 Apr 2009, Mauro Carvalho Chehab wrote:
On Sun, 05 Apr 2009 18:00:04 -0400
Andy Walls awa...@radix.net wrote:
On Sun, 2009-04-05 at 23:22 +0200, hermann pitton wrote:
Am Sonntag, den 05.04.2009, 22:22 +0200 schrieb Jean Delvare:
On Sun, 05 Apr 2009 14:58:17 -0400, Andy Walls wrote:
What can not be translated to the input system I would like to know.
Andy seems to have closer looked into that.
1. IR blasting: sending IR codes to transmit out to a cable convertor
box, DTV to analog convertor box, or similar devices to change channels
before recording starts. An input interface doesn't work well for
output.
On my understanding, IR output is a separate issue. AFAIK, only a very few
ivtv
devices support IR output. I'm not sure how this is currently implemented.
For the pvrusb2 driver, MCE style 24xxx devices (2nd generation 24xxx)
and HVR-1950 devices have IR blasting capabilities. At the moment,
people have gotten this to work on the 24xxx model with the appropriate
lirc driver. In theory it should be doable for HVR-1950 as well (and
the pvrusb2 does what is needed to make it possible) but I don't think
anyone has succeeded there yet.
Sure IR output as a concept and interface is a separate issue. But it
can be implemented in the same chip (which is the case in the two
examples I list above). So the issue is not separate; it must be dealt
with as a whole. Two drivers implementing different features but trying
to share one chip is just not fun.
Yes, this should be considered by the same driver, but perhaps not using the
same userspace API. I'm not sure if event interface allows such usage.
If the driver processes correctly the IR samples, I don't see why you would
need to pass the raw protocols to userspace. Maybe we need to add some
ioctls
at the API to allow certain controls, like, for example, ask kernel to
decode
IR using RC4 instead or RC5, on devices that supports more than one IR
protocol.
Ugh. Why should v4l-dvb get into this business when it's already solved
somewhere else? In userspace even.
I see in so many other places people arguing for V4L functionality that
needs to be kicked out of the kernel and put into userspace. For
example, there's all that silliness over pixel formats that I'm soon
going to have to deal with...
Removing kernel functionality breaks compatibility with legacy applications.
Yet in this case with IR, there already exists a subsystem that does
*more* than ir-kbd-i2c.c, AND it does all the crazy configuration /
control in userspace - and yet you argue that ir-kbd-i2c.c should be
preferred? Purely because lirc is not in-tree?
Setting up lirc to work it is a way more complex that just plugging a
device and having IR working. For all my usages here, I prefer to just load a
different IR table than having to deal with lirc configuration stuff.
It should be users option to use lirc or just rely on the existing IR support.
Well heck, lirc should be in-tree. Let's help them get there and forget ever
having to deal
with IR again ourselves. Let them do it.
I agree that we should help with this. IMO, the proper way for lirc drivers for
media devices is that they should include linux-media oh the discussions about
the inclusion of those drivers, in a way that just one driver would be used,
and that the event interface will keep working by default, as currently.
I just looked at this. I freely admit I haven't noticed this before,
but having looked at it now, and having examined ir-kbd-i2c.c, I still
don't see the whole picture here:
1. The switch statement in ir-kbd-i2c.c:ir_attach() is apparently
implicitly trying to assume a particular type of remote based on the I2C
address of the IR receiver it's talking to. Yuck. That's really not
right at all. The IR receiver used does not automatically mean which
remote is used. What if the vendor switches remotes? That's happened
with the PVR-USB2 hardware in the past (based on photos I've seen).
Who's to say the next remote to be supplied is compatible?
This is the legacy model, kept there only due to the fact that we don't really
know with 100% sure what boards were using those functions. For the new model,
you should take a look on a bridge driver, like, for example, on em28xx-cards:
void em28xx_set_ir(struct em28xx *dev, struct IR_i2c *ir)
{
if (disable_ir) {
ir-get_key = NULL;
return ;
}
/* detect configure */
switch (dev-model) {
case (EM2800_BOARD_UNKNOWN):
break;
case (EM2820_BOARD_UNKNOWN):
break;
case (EM2800_BOARD_TERRATEC_CINERGY_200):
case (EM2820_BOARD_TERRATEC_CINERGY_250):
ir-ir_codes = ir_codes_em_terratec;
[PATCH 1/3] Documentation for new V4L2 CIDs added.
1. Updated for V4L2_CID_BG_COLOR 2. Updated for V4L2_CID_ROTATION Both of the above are discussed in length with community 3. Updated for new flags and capability field added to v4l2_frame buffer structure. Community comments fixed in this post 1. Fixed Few typos. 2. Changed V4L2_CID_ROTATION to V4L2_CID_ROTATE 3. Re-framed source chroma keying related explanation Signed-off-by: Brijesh Jadav brijes...@ti.com Signed-off-by: Hardik Shah hardik.s...@ti.com Signed-off-by: Vaibhav Hiremath hvaib...@ti.com --- v4l2-spec/controls.sgml | 19 ++- v4l2-spec/vidioc-g-fbuf.sgml | 19 +++ 2 files changed, 37 insertions(+), 1 deletions(-) diff --git a/v4l2-spec/controls.sgml b/v4l2-spec/controls.sgml index 477a970..3a91061 100644 --- a/v4l2-spec/controls.sgml +++ b/v4l2-spec/controls.sgml @@ -281,10 +281,27 @@ minimum value disables backlight compensation./entry constantV4L2_COLORFX_SEPIA/constant (2)./entry /row row + entryconstantV4L2_CID_ROTATE/constant/entry + entryinteger/entry + entryRotates the image by specified angle. Common angles are 90, 270, +and 180. Rotating the image to 90 and 270 will reverse the height and width of +the display window. It is necessary to set the new height and width of the picture +using S_FMT ioctl see xref linkend=vidioc-g-fmt according to the rotation angle selected/entry + /row + row + entryconstantV4L2_CID_BG_COLOR/constant/entry + entryinteger/entry + entrySets the background color of the current output device. +Background color needs to be specified in the RGB24 format. The supplied 32 +bit value is intepreted as Bits 0-7 Red color information, Bits 8-15 Green color +information, Bits 16-23 Blue color information and Bits 24-31 must be +zero./entry + /row + row entryconstantV4L2_CID_LASTP1/constant/entry entry/entry entryEnd of the predefined control IDs (currently -constantV4L2_CID_COLORFX/constant + 1)./entry +constantV4L2_CID_BG_COLOR/constant + 1)./entry /row row entryconstantV4L2_CID_PRIVATE_BASE/constant/entry diff --git a/v4l2-spec/vidioc-g-fbuf.sgml b/v4l2-spec/vidioc-g-fbuf.sgml index 6781b53..13c9ac6 100644 --- a/v4l2-spec/vidioc-g-fbuf.sgml +++ b/v4l2-spec/vidioc-g-fbuf.sgml @@ -336,6 +336,13 @@ alpha value. Alpha blending makes no sense for destructive overlays./entry inverted alpha channel of the framebuffer or VGA signal. Alpha blending makes no sense for destructive overlays./entry /row + row + entryconstantV4L2_FBUF_CAP_SRC_CHROMAKEY/constant/entry + entry0x0080/entry + entryThe device supports source chroma keying. Video pixels + with the chromakey color are replaced by the framebuffer pixels. + Exactly opposite of constantV4L2_FBUF_CAP_CHROMAKEY/constant/entry + /row /tbody /tgroup /table @@ -411,6 +418,18 @@ images, but with an inverted alpha value. The blend function is: output = framebuffer pixel * (1 - alpha) + video pixel * alpha. The actual alpha depth depends on the framebuffer pixel format./entry /row + row + entryconstantV4L2_FBUF_FLAG_SRC_CHROMAKEY/constant/entry + entry0x0040/entry + entryUse source chroma-keying. The chroma-key color is +determined by the structfieldchromakey/structfield field of +v4l2-window; and negotiated with the VIDIOC-S-FMT; ioctl, see xref +linkend=overlay and xref linkend=osd. +Since any one of the chroma keying can be active at a time as both +of them are exactly opposite, the same structfieldchromakey/structfield +field of v4l2-window; can be used to set the chroma key for source +keying also./entry + /row /tbody /tgroup /table -- 1.6.0.3 -- 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 2/3] New V4L2 CIDs for OMAP class of Devices.
Added V4L2_CID_BG_COLOR for background color setting.
Added V4L2_CID_ROTATION for rotation setting.
Above two ioclts are indepth discussed. Posting
again with the driver usage.
V4L2 supports chroma keying added new flags for the
source chroma keying which is exactly opposite of the
chorma keying supported by V4L2.
In current implementation framebuffer pixels with
the chromakey color are replaced by video pixels.
While for the source chroma keying video pixels with
the chromakey color are replaced by the framebuffer
pixels.
Both are exactly opposite and so are mutually exclusive
Community Comments fixed in this post
1. Replaced V4L2_CID_ROTATION by V4L2_CID_ROTATE.
2. Initilize min and max values for V4L2_CID_BG_COLOR
control id.
3. Other minor comments fixed
Signed-off-by: Brijesh Jadav brijes...@ti.com
Signed-off-by: Hardik Shah hardik.s...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
linux/drivers/media/video/v4l2-common.c |9 +
linux/include/linux/videodev2.h |6 +-
2 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/linux/drivers/media/video/v4l2-common.c
b/linux/drivers/media/video/v4l2-common.c
index d75d89c..e44b432 100644
--- a/linux/drivers/media/video/v4l2-common.c
+++ b/linux/drivers/media/video/v4l2-common.c
@@ -422,6 +422,8 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_CHROMA_AGC: return Chroma AGC;
case V4L2_CID_COLOR_KILLER: return Color Killer;
case V4L2_CID_COLORFX: return Color Effects;
+ case V4L2_CID_ROTATE: return Rotate;
+ case V4L2_CID_BG_COLOR: return Background color;
/* MPEG controls */
case V4L2_CID_MPEG_CLASS: return MPEG Encoder Controls;
@@ -547,6 +549,13 @@ int v4l2_ctrl_query_fill(struct v4l2_queryctrl *qctrl, s32
min, s32 max, s32 ste
qctrl-flags |= V4L2_CTRL_FLAG_READ_ONLY;
min = max = step = def = 0;
break;
+ case V4L2_CID_BG_COLOR:
+qctrl-type = V4L2_CTRL_TYPE_INTEGER;
+step = 1;
+min = 0;
+/* Max is calculated as RGB888 that is 2^12*/
+max = 0xFF;
+break;
default:
qctrl-type = V4L2_CTRL_TYPE_INTEGER;
break;
diff --git a/linux/include/linux/videodev2.h b/linux/include/linux/videodev2.h
index 82f9e72..f4cd39b 100644
--- a/linux/include/linux/videodev2.h
+++ b/linux/include/linux/videodev2.h
@@ -549,6 +549,7 @@ struct v4l2_framebuffer {
#define V4L2_FBUF_CAP_LOCAL_ALPHA 0x0010
#define V4L2_FBUF_CAP_GLOBAL_ALPHA 0x0020
#define V4L2_FBUF_CAP_LOCAL_INV_ALPHA 0x0040
+#define V4L2_FBUF_CAP_SRC_CHROMAKEY0x0080
/* Flags for the 'flags' field. */
#define V4L2_FBUF_FLAG_PRIMARY 0x0001
#define V4L2_FBUF_FLAG_OVERLAY 0x0002
@@ -556,6 +557,7 @@ struct v4l2_framebuffer {
#define V4L2_FBUF_FLAG_LOCAL_ALPHA 0x0008
#define V4L2_FBUF_FLAG_GLOBAL_ALPHA0x0010
#define V4L2_FBUF_FLAG_LOCAL_INV_ALPHA 0x0020
+#define V4L2_FBUF_FLAG_SRC_CHROMAKEY 0x0040
struct v4l2_clip {
struct v4l2_rectc;
@@ -888,6 +890,8 @@ enum v4l2_power_line_frequency {
#define V4L2_CID_CHROMA_AGC (V4L2_CID_BASE+29)
#define V4L2_CID_COLOR_KILLER (V4L2_CID_BASE+30)
#define V4L2_CID_COLORFX (V4L2_CID_BASE+31)
+#define V4L2_CID_ROTATE(V4L2_CID_BASE+32)
+#define V4L2_CID_BG_COLOR (V4L2_CID_BASE+33)
enum v4l2_colorfx {
V4L2_COLORFX_NONE = 0,
V4L2_COLORFX_BW = 1,
@@ -895,7 +899,7 @@ enum v4l2_colorfx {
};
/* last CID + 1 */
-#define V4L2_CID_LASTP1 (V4L2_CID_BASE+32)
+#define V4L2_CID_LASTP1 (V4L2_CID_BASE+34)
/* MPEG-class control IDs defined by V4L2 */
#define V4L2_CID_MPEG_BASE (V4L2_CTRL_CLASS_MPEG | 0x900)
--
1.6.0.3
--
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: tm6010 development repository
Kevin Wells wrote: Mauro Carvalho Chehab wrote: On Sun, 05 Apr 2009 12:45:56 +1200 Kevin Wells wells_ke...@yahoo.co.nz wrote: Steven Toth wrote: Kevin Wells wrote: I've started trying to understand the code in the following repository: http://www.linuxtv.org/hg/~mchehab/tm6010/ I have a few patches I would like to apply. How should I do this? Submit the patches to the list and I'll try to get some time to create and maintain a ~stoth/tm6010 tree. I think I can get the nova-s-usb2 running with just a little effort. Patches to follow. Nothing exciting. Just trying to make the code more robust. Patches are very granular. Let me know if that doesn't work for you. I'll merge those with some patches I have here. hvr-900h analog part is working with a some troubles on the experimental tree I have here. A good thing to do, after I merge yours and my patches, is to convert it to the new v4l2 dev/subdev interface. I suspect that this will solve several bugs we currently have with the i2c interface of this driver. I intend to do this later this week, after the end of the merge window. For now, I still have lots of patches to review, in order to submit for 2.6.30. Thanks Mauro. Thanks Kevin. Mauro, Let me know when you've done this and I'll clone your tree and look at the nova-s-usb2 issues. Thanks, - Steve -- 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: v4l-dvb repository doesn't build
On Mon, 6 Apr 2009 10:32:52 +0200, Jean Delvare wrote: My latest pull of the v4l-dvb repository this morning broke the build: make[3]: *** No rule to make target `/home/khali/src/v4l-dvb/v4l/cx88-dsp.o', needed by `/home/khali/src/v4l-dvb/v4l/tda18271.o'. Stop. I am building against kernel 2.6.29.1. Yesterday it was building OK. I can't make any sense of this error. Help anyone? For the records: that was a missing file in the repository, Mauro just fixed it. -- Jean Delvare -- 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 3/6] ir-kbd-i2c: Switch to the new-style device binding model
On Sun, 05 Apr 2009 08:44:15 -0400 Andy Walls awa...@radix.net wrote: The scope of a complete kernel IR infrastructure goes a bit beyond I2C bus devices that are only input devices. What's the scope of what you want to tackle here? I certainly don't want to reinvent something that's going to look just like the LIRC driver model: http://www.lirc.org/html/technical.html Which already has an infrastructure for IR driver module writers: http://www.lirc.org/html/technical.html#lirc_dev As other out-of-tree drivers that have a long trip, I suspect that lirc did some assumptions, while event and v4l did different ones. Due to kernel rules to keep API's forever, we should take some care to avoid breaking the existing API in favor to another one. So, this probably means some lirc redesign, in order to get his way to kernel, on a similar path that ivtv driver did. The part of lirc that I'm concerned with are the ones that work with GPIO and I2C devices and the API. Do we just convert lirc_dev, lirc_i2c, and lirc_zilog to a cleaned up set of in kernel modules? We should cover also the lirc gpio module(s). lirc_i2c can certainly be broken up into several modules: 1 per supported device. I don't think that breaking it into one per device is the better approach. IMO, we need a common i2c glue (like what ir-kbd-i2c provides, if we remove the legacy stuff) that it is IR independent. the IR dependent parts can be part of ir-common module or eventually we can split it into sub-modules. Should these create an input device as well to maintain compatability with apps expecting an ir-kbd-i2c like function? For sure. The event interface is the kernel way for input devices. There are also other IR devices (like IR mouses and keyboards) already handled via input/event interface. On a first glance, I don't see the need to exporting raw data to userspace, although I understand why lirc needs this currently. Or do we split up ir-kbd-i2c into per device modules and in addition to the input event interface, have it register with the lirc_dev module? Do we leverage LIRC's lirc_dev infrastructure module at all? (I think it would be a waste of time not to do so.) IMO, the proper workflow would be to discuss lirc as a hole with Lirc people, linux-media and input/event people. 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 3/3] V4L2 Driver for OMAP3/3 DSS.
Hi Hans,
Please find my comments inline. Most of the comments are taken care of.
2. In DSS rotation is accomplished by some memory algorithm but its quite
costly so -1 is essentially same as 0 degree but with out the overhead.
But if mirroring is on then we have to do the 0 degree rotation with
overhead using some memory techniques. So from user point of view he will
only be setting 0 but internally driver will take it as -1 or 0 depending
upon the mirroring selected.
Hi Hardik,
I just looked over these comments and I'll do a full review in the weekend
when I'm back from San Francisco. But just one quick remark regarding this
magic -1 number: wouldn't it be better to write a small inline function
like this:
/* return true if we need to rotate or mirror, return false if we
don't have to do anything here. */
static inline int needs_rotate(struct foo *foo)
{
return foo-rotate != 0 || foo-mirror;
}
I think this is much more understandable. It's up to you, though.
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: [PULL] http://linuxtv.org/hg/~mcisely/pvrusb2
On Mon, 6 Apr 2009, Jean Delvare wrote: Hi Mike, I'll answer all your questions and express my concerns in this reply, to avoid spreading the info all around the discussion thread. On Mon, 6 Apr 2009 00:19:23 -0500 (CDT), Mike Isely wrote: Please pull from http://linuxtv.org/hg/~mcisely/pvrusb2 for two pvrusb2 changesets. One sets up the ability to track what kind of IR receiver is expected, Looks very good. The more we know about each board, the less probing we have to do, the better. the other optionally autoloads ir-kbd-i2c based on that result and a module option that can be used to disable that autoloading. Again, ir-kbd-i2c does _not_ auto-load. What my code (and now yours) does is instantiating an i2c device named ir-kbd. _If_ the ir-kbd-i2c driver is later loaded, it will bind to that device. We might let udev load the ir-kbd-i2c driver at some point in the future, but clearly we need to sort out the lirc case beforehand, otherwise some users will hit the problems you have anticipated, and we don't want this to happen. So, your module parameter is improperly named. Setting it to 1 does prevent the pvrusb2 driver from instantiating the ir-kbd device, and that's all. The module parameter is named disabled_autoload_ir_kbd, how is that wrong? The name is based on the internal receiver name ir-kbd. There's no [-_]i2c in the name. The parameter's description also does not reference ir-kbd-i2c by name either. I did it that way specifically for the reason you point out here. I was originally going to use the name that Hans had suggested but then decided otherwise because (1) I decided to follow your desire and make it a disable option, (2) Hans' suggested name did in fact encode the name ir-kbd-i2c in the module option. Speaking of this module parameter, I was a little worried at first that you wanted an inverted logic for it in pvrusb2 compared to what some other bridge drivers (saa7134, em28xx, cx231xx), but thinking a bit more about I came to the conclusion that it was OK because it matched the history of the pvrusb2 driver. Now I see that you followed their logic (enabled is the default) but you use a different module parameter name (disable_autoload_ir_kbd vs. disable_ir). I think there would be some value in sticking to a common name in all bridge drivers (like we have the standard video_nr module parameter.) That being said, I will not insist on this. My feeling is that this is all temporary anyway, because the removal of the legacy i2c model will break lirc and the main point is to decide how we will fix it. I'll post a separate summary with proposals. Depending on what we do, the module parameter you added is likely to become obsolete. I did want it to be an enable parameter, in order to match previous driver behavior. But whether it is an enable or a disable option, in one use-case somebody has to set it. So I relented and made it a disable option. This is the result of what I had posted about an hour ago. It looks like a lot of lines, but it was all basically trivial stuff. Note that these changes are safe; nothing is regressed here and this does not depend on anyone else's changes. Even though that second changeset won't really do much until Jean's ir-kbd-i2c stuff is merged, the fact is that it won't cause any harm either. Since the pvrusb2 driver wasn't previously autoloading ir-kbd-i2c anyway, this change therefore breaks nothing. For completeness, your second patch actually breaks the ir-kbd-i2c use case. Your code will instantiate a new-style ir-kbd device which the legacy ir-kbd-i2c can't use. As the instantiated device makes the address busy, the probing logic of legacy ir-kbd-i2c driver will skip it. Without my changes, all users will have to pass disable_autoload_ir_kbd=1, whether they want to use lirc or ir-kbd-i2c, otherwise they lose IR support. Well yes. I was saying no harm in the sense that everything that was possible before is still possible now, though perhaps with the module option set. But honestly that doesn't matter much, I think, because the idea is to merge my changes quickly. Yes, exactly. [...] This morning I actually realized another use-case that has been missed. It was likely an issue before anyway, but it got me thinking about this: If a user has multiple devices attached to one system, he probably won't want all of the corresponding IR receivers enabled - that would just trigger redundant input events. With a PCI-hosted ivtv device this is not really an issue - because there one can just decline to plug in the actual IR sensor. But with USB-hosted devices, the IR sensor is an integral part of the device and can't be unplugged. OK, well such a user could instead just choose to put a piece of tape over the window or stick all but one device in a box (and causing potential heat problems if it isn't ventilated), but
Re: [PATCH] Add ov9655 camera driver
On Mon, 6 Apr 2009, Stefan Herbrechtsmeier wrote: Add a driver for the OmniVision ov9655 camera sensor. The driver use the soc_camera framework. It was tested on the BeBot robot with a PXA270 processor. Signed-off-by: Stefan Herbrechtsmeier hbme...@hni.uni-paderborn.de Hans, does it make sense to include this one or shall we wait for gspca on this one too? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- 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 Mike, Please note: I think the long post I just sent makes part of this discussion obsolete from a technical perspective. But still interesting from a functional perspective, which is why I am following up. On Mon, 6 Apr 2009 10:03:00 -0500 (CDT), Mike Isely wrote: On Mon, 6 Apr 2009, Jean Delvare wrote: Again, ir-kbd-i2c does _not_ auto-load. What my code (and now yours) does is instantiating an i2c device named ir-kbd. _If_ the ir-kbd-i2c driver is later loaded, it will bind to that device. We might let udev load the ir-kbd-i2c driver at some point in the future, but clearly we need to sort out the lirc case beforehand, otherwise some users will hit the problems you have anticipated, and we don't want this to happen. So, your module parameter is improperly named. Setting it to 1 does prevent the pvrusb2 driver from instantiating the ir-kbd device, and that's all. The module parameter is named disabled_autoload_ir_kbd, how is that wrong? The name is based on the internal receiver name ir-kbd. There's no [-_]i2c in the name. The parameter's description also does not reference ir-kbd-i2c by name either. I did it that way specifically for the reason you point out here. I was perfectly fine with the ir_kbd part. The part I complain about is autoload, because the original mechanism doesn't involve any autoloading. (...) For completeness, your second patch actually breaks the ir-kbd-i2c use case. Your code will instantiate a new-style ir-kbd device which the legacy ir-kbd-i2c can't use. As the instantiated device makes the address busy, the probing logic of legacy ir-kbd-i2c driver will skip it. Without my changes, all users will have to pass disable_autoload_ir_kbd=1, whether they want to use lirc or ir-kbd-i2c, otherwise they lose IR support. Well yes. I was saying no harm in the sense that everything that was possible before is still possible now, though perhaps with the module option set. We agree then. (...) This morning I actually realized another use-case that has been missed. It was likely an issue before anyway, but it got me thinking about this: If a user has multiple devices attached to one system, he probably won't want all of the corresponding IR receivers enabled - that would just trigger redundant input events. With a PCI-hosted ivtv device this is not really an issue - because there one can just decline to plug in the actual IR sensor. But with USB-hosted devices, the IR sensor is an integral part of the device and can't be unplugged. OK, well such a user could instead just choose to put a piece of tape over the window or stick all but one device in a box (and causing potential heat problems if it isn't ventilated), but that approach is well, inelegant. I think this argues for a better solution in the bridge driver to selectively disable IR on a per-device instance basis. There's already some logic in the pvrusb2 driver to do this, but it's clumsy and wasn't intended to solve that particular use-case. I need to consider this further and do some cleanup. This use-case may actually suggest the disable option should be expanded and possibly made permanent. I agree. I presume that this is one of the reasons why some bridge drivers have a disable_ir parameter (the other reason being lirc). It would probably make sense to not only keep these module parameters even after lirc is merged into the kernel tree, but turn them into arrays, so that IR receivers can be disabled selectively. This would address the problem you just raised. But all this can be done after the conversion work it finished. -- Jean Delvare -- 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 Mon, 6 Apr 2009, Jean Delvare wrote: Hi Mike, Please note: I think the long post I just sent makes part of this discussion obsolete from a technical perspective. But still interesting from a functional perspective, which is why I am following up. I plan a reply to your RFC as well, probably later on tonight. On Mon, 6 Apr 2009 10:03:00 -0500 (CDT), Mike Isely wrote: On Mon, 6 Apr 2009, Jean Delvare wrote: Again, ir-kbd-i2c does _not_ auto-load. What my code (and now yours) does is instantiating an i2c device named ir-kbd. _If_ the ir-kbd-i2c driver is later loaded, it will bind to that device. We might let udev load the ir-kbd-i2c driver at some point in the future, but clearly we need to sort out the lirc case beforehand, otherwise some users will hit the problems you have anticipated, and we don't want this to happen. So, your module parameter is improperly named. Setting it to 1 does prevent the pvrusb2 driver from instantiating the ir-kbd device, and that's all. The module parameter is named disabled_autoload_ir_kbd, how is that wrong? The name is based on the internal receiver name ir-kbd. There's no [-_]i2c in the name. The parameter's description also does not reference ir-kbd-i2c by name either. I did it that way specifically for the reason you point out here. I was perfectly fine with the ir_kbd part. The part I complain about is autoload, because the original mechanism doesn't involve any autoloading. But from the viewpoint of a user of the pvrusb2 driver, that is in fact what will appear to happen. 1. User plugs in device. 2. Driver (pvrusb2) instantiates self. 3. Driver automatically attempts to load and bind ir-kbd-i2c to the IR receiver, hence autoload. Yes I know ir-kbd-i2c no longer autoloads itself; that is a major goal of the conversion. But with the pvrusb2 change to explicitly bind it, the behavior from the view of the user is still that of an autoload operation. I think we're just arguing semantics, but it's why I put autoload in the name. However given the realization below about multiple devices, I think I need to step back and look at this from a larger scope (e.g. make it an array, merge with the fairly clunky ir_mode switch already in the driver and clean that up, etc). [...] This morning I actually realized another use-case that has been missed. It was likely an issue before anyway, but it got me thinking about this: If a user has multiple devices attached to one system, he probably won't want all of the corresponding IR receivers enabled - that would just trigger redundant input events. With a PCI-hosted ivtv device this is not really an issue - because there one can just decline to plug in the actual IR sensor. But with USB-hosted devices, the IR sensor is an integral part of the device and can't be unplugged. OK, well such a user could instead just choose to put a piece of tape over the window or stick all but one device in a box (and causing potential heat problems if it isn't ventilated), but that approach is well, inelegant. I think this argues for a better solution in the bridge driver to selectively disable IR on a per-device instance basis. There's already some logic in the pvrusb2 driver to do this, but it's clumsy and wasn't intended to solve that particular use-case. I need to consider this further and do some cleanup. This use-case may actually suggest the disable option should be expanded and possibly made permanent. I agree. I presume that this is one of the reasons why some bridge drivers have a disable_ir parameter (the other reason being lirc). It would probably make sense to not only keep these module parameters even after lirc is merged into the kernel tree, but turn them into arrays, so that IR receivers can be disabled selectively. This would address the problem you just raised. But all this can be done after the conversion work it finished. I believe I can solve this for the pvrusb2 driver without entanglement with the conversion work underway. Pieces of the solution are already in the driver; I just need to clean this up. In any case, I'm not going to worry about it immediately. I've been neglecting some non-Linux tasks, like filing bills and finishing my tax return :-) -Mike -- Mike Isely isely @ pobox (dot) com PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: WARNINGS, 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:Mon Apr 6 19:00:05 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 11397:02fde69f31dc gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29-armv5: OK linux-2.6.27-armv5-ixp: WARNINGS linux-2.6.28-armv5-ixp: OK linux-2.6.29-armv5-ixp: OK linux-2.6.28-armv5-omap2: OK linux-2.6.29-armv5-omap2: OK linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29-i686: OK linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29-m32r: OK linux-2.6.22.19-mips: OK linux-2.6.26-mips: OK linux-2.6.27-mips: OK linux-2.6.28-mips: OK linux-2.6.29-mips: OK linux-2.6.27-powerpc64: OK linux-2.6.28-powerpc64: OK linux-2.6.29-powerpc64: OK linux-2.6.22.19-x86_64: OK linux-2.6.23.12-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29-x86_64: OK fw/apps: OK sparse (linux-2.6.29): OK linux-2.6.16.61-i686: WARNINGS linux-2.6.17.14-i686: OK linux-2.6.18.8-i686: OK linux-2.6.19.5-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.16.61-x86_64: WARNINGS linux-2.6.17.14-x86_64: OK linux-2.6.18.8-x86_64: OK linux-2.6.19.5-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Support for Legend Silicon LGS8913/LGS8GL5/LGS8GXX China DMB-TH digital demodulator
On Tue, 31 Mar 2009 00:54:49 -0400 Devin Heitmueller devin.heitmuel...@gmail.com wrote: On Tue, Mar 17, 2009 at 11:55 AM, David Wong davidtlw...@gmail.com wrote: This patch contains the unified driver for Legend Silicon LGS8913 and LGS8GL5. It should replace lgs8gl5.c in media/dvb/frontends David T.L. Wong David, The questions you posed tonight on a separate thread about making the xc5000 work with this device prompts the question: Do you know that this driver you submitted actually works? Have you successfully achieved lock with this driver and been able to view the stream? It is great to see the improvements and more generic support, but if you don't have it working in at least one device, then it probably shouldn't be submitted upstream yet, and it definitely should not be replacing an existing driver. We need to do some tests before replacing the existing one. Yet, it is better to have a generic device than specific ones. Do you have any card with lg8gl5? If so, could you please test the new driver for us? Anyway, I'm applying what we currently have. 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
Fw: [PATCH resend] UVC: uvc_status_cleanup(): undefined reference to `input_unregister_device'
Forwarded message: Date: Mon, 6 Apr 2009 14:57:55 -0700 From: Randy Dunlap randy.dun...@oracle.com To: Mauro Carvalho Chehab mche...@redhat.com,lkml linux-ker...@vger.kernel.org Cc: Laurent Pinchart laurent.pinch...@skynet.be,Rafael J. Wysocki r...@sisk.pl Subject: [PATCH resend] UVC: uvc_status_cleanup(): undefined reference to `input_unregister_device' From: Randy Dunlap randy.dun...@oracle.com Fix build errors when USB_VIDEO_CLASS=y and INPUT=m. Fixes kernel bugzilla #12671. Signed-off-by: Randy Dunlap randy.dun...@oracle.com Acked-by: Laurent Pinchart laurent.pinch...@skynet.be --- drivers/media/video/uvc/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- mmotm-2009-0214-0049.orig/drivers/media/video/uvc/Kconfig +++ mmotm-2009-0214-0049/drivers/media/video/uvc/Kconfig @@ -9,7 +9,7 @@ config USB_VIDEO_CLASS config USB_VIDEO_CLASS_INPUT_EVDEV bool UVC input events device support default y - depends on USB_VIDEO_CLASS INPUT + depends on USB_VIDEO_CLASS=INPUT || INPUT=y ---help--- This option makes USB Video Class devices register an input device to report button events. -- 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: Embedded Linux Conference
* Dongsoo Kim dongsoo@gmail.com [090317 10:36]: snip snip How about Monday night after the Dinner (ends at 7pm [1]) we meet for beers. I'll let someone local (Tony) pick the venue. OK, let's plan for Monday night then. I'll find some place with drinks easily available, and within walking distance from the conference. I've added a placeholder for the event where I'll post the details later on: http://www.muru.com/linux/omap/events/ OK, let's meet at Harry's bar 7pm at 2020 Fillmore St between Pine and California St. They're closed until 4pm, so there's no reservation. But as it's Monday night, I'd assume there's plenty of space. In case of last minute changes, please check the page above. Tony -- 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] Re: cx88-dsp.c: missing __divdi3 on 32bit kernel
Well this patch should solve it.
I don't know how many samples are processed so:
First patch is for situation when N*N fits in s32.
Second one uses two divisions, but doesn't have any abnormal restrictions for N.
Personally I think that two divisions won't hurt. :)
- FILE: cx88-dsp_64bit_math1.patch -
cx88-dsp: fixing 64bit math on 32bit kernels
Note the limitation of N.
Personally I know nothing about possible size of samples array.
From: Miroslav Sustek sustmid...@centrum.cz
Signed-off-by: Miroslav Sustek sustmid...@centrum.cz
diff -r 8aa1d865373c linux/drivers/media/video/cx88/cx88-dsp.c
--- a/linux/drivers/media/video/cx88/cx88-dsp.c Wed Apr 01 20:25:00 2009 +
+++ b/linux/drivers/media/video/cx88/cx88-dsp.c Tue Apr 07 00:08:48 2009 +0200
@@ -100,13 +100,22 @@
s32 s_prev2 = 0;
s32 coeff = 2*int_cos(freq);
u32 i;
+
+ s64 tmp;
+ u32 remainder;
+
for (i = 0; i N; i++) {
s32 s = x[i] + ((s64)coeff*s_prev/32768) - s_prev2;
s_prev2 = s_prev;
s_prev = s;
}
- return (u32)(((s64)s_prev2*s_prev2 + (s64)s_prev*s_prev -
- (s64)coeff*s_prev2*s_prev/32768)/N/N);
+
+ tmp = (s64)s_prev2*s_prev2 + (s64)s_prev*s_prev -
+ (s64)coeff*s_prev2*s_prev/32768;
+
+ /* XXX: N must be low enough so that N*N fits in s32.
+* Else we need two divisions. */
+ return (u32) div_s64_rem(tmp, N*N, remainder);
}
static u32 freq_magnitude(s16 x[], u32 N, u32 freq)
- FILE: cx88-dsp_64bit_math2.patch -
cx88-dsp: fixing 64bit math on 32bit kernels
From: Miroslav Sustek sustmid...@centrum.cz
Signed-off-by: Miroslav Sustek sustmid...@centrum.cz
diff -r 8aa1d865373c linux/drivers/media/video/cx88/cx88-dsp.c
--- a/linux/drivers/media/video/cx88/cx88-dsp.c Wed Apr 01 20:25:00 2009 +
+++ b/linux/drivers/media/video/cx88/cx88-dsp.c Tue Apr 07 00:26:10 2009 +0200
@@ -100,13 +100,22 @@
s32 s_prev2 = 0;
s32 coeff = 2*int_cos(freq);
u32 i;
+
+ s64 tmp;
+ u32 remainder;
+
for (i = 0; i N; i++) {
s32 s = x[i] + ((s64)coeff*s_prev/32768) - s_prev2;
s_prev2 = s_prev;
s_prev = s;
}
- return (u32)(((s64)s_prev2*s_prev2 + (s64)s_prev*s_prev -
- (s64)coeff*s_prev2*s_prev/32768)/N/N);
+
+ tmp = (s64)s_prev2*s_prev2 + (s64)s_prev*s_prev -
+ (s64)coeff*s_prev2*s_prev/32768;
+
+ tmp = div_s64_rem(tmp, N, remainder);
+
+ return (u32)div_s64_rem(tmp, N, remainder);
}
static u32 freq_magnitude(s16 x[], u32 N, u32 freq)
--
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: Embedded Linux Conference
* Dongsoo Kim dongsoo@gmail.com [090317 10:36]: snip snip How about Monday night after the Dinner (ends at 7pm [1]) we meet for beers. I'll let someone local (Tony) pick the venue. OK, let's plan for Monday night then. I'll find some place with drinks easily available, and within walking distance from the conference. I've added a placeholder for the event where I'll post the details later on: http://www.muru.com/linux/omap/events/ OK, let's meet at Harry's bar 7pm at 2020 Fillmore St between Pine and California St. They're closed until 4pm, so there's no reservation. But as it's Monday night, I'd assume there's plenty of space. In case of last minute changes, please check the page above. Not sure whether it will be as quiet as you hope: http://www.harrysbarsf.com/ There's apparently some championship game going on today. Note that I and a few others will meet up in the hotel's lobby at 6pm to go to have dinner somewhere. Whoever is interested is free to join us. 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: Embedded Linux Conference
On Tue, Apr 07, 2009 at 01:18:05AM +0200, Hans Verkuil wrote: * Dongsoo Kim dongsoo@gmail.com [090317 10:36]: snip snip How about Monday night after the Dinner (ends at 7pm [1]) we meet for beers. I'll let someone local (Tony) pick the venue. OK, let's plan for Monday night then. I'll find some place with drinks easily available, and within walking distance from the conference. I've added a placeholder for the event where I'll post the details later on: http://www.muru.com/linux/omap/events/ OK, let's meet at Harry's bar 7pm at 2020 Fillmore St between Pine and California St. They're closed until 4pm, so there's no reservation. But as it's Monday night, I'd assume there's plenty of space. In case of last minute changes, please check the page above. Not sure whether it will be as quiet as you hope: http://www.harrysbarsf.com/ There's apparently some championship game going on today. Just spoke withem on the phone, they'll just have some basketball on tv. So let's meet there and if it's too loud we can go somewhere else. Note that I and a few others will meet up in the hotel's lobby at 6pm to go to have dinner somewhere. Whoever is interested is free to join us. Regards, There are some nice Japanese restaurants in mall next to the hotel. Regards, Tony -- 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: [GIT PATCHES for 2.6.30] V4L/DVB updates
On Mon, 6 Apr 2009, Mauro Carvalho Chehab wrote: Please pull from: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git for_linus Have you rebased your tree and pushed out multiple versions of it? I'm getting very confusing things from the mirrors, which are subtly different from the copy on master. This all looks like it was rebased just hours ago, and to top it off, it looks like you actually change stuff you had exported earlier. Don't do that. Really. It's very annoying. More than annoying, in fact. This had better simply not happen again! Linus -- 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: [GIT PATCHES for 2.6.30] V4L/DVB updates
On Mon, 6 Apr 2009 18:11:34 -0700 (PDT) Linus Torvalds torva...@linux-foundation.org wrote: On Mon, 6 Apr 2009, Mauro Carvalho Chehab wrote: Please pull from: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git for_linus Have you rebased your tree and pushed out multiple versions of it? I'm getting very confusing things from the mirrors, which are subtly different from the copy on master. This all looks like it was rebased just hours ago, and to top it off, it looks like you actually change stuff you had exported earlier. Don't do that. Really. It's very annoying. More than annoying, in fact. This had better simply not happen again! Yes, unfortunately I had to rebase. I noticed that one of the patches were creating a file that didn't belong to that changeset, creating a file on the wrong place (at -p2 diff format). We should be discussing during this kernel cycle about migrating our development tree to use -git (instead of Mercurial). I hope that this will avoid to detect such errors so late, and avoid a few conversion issues we currently have. Sorry for the mess. -- 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] Support for Legend Silicon LGS8913/LGS8GL5/LGS8GXX China DMB-TH digital demodulator
Dear Mauro, I wrote the original lgs8gl5 driver by reverse-engineering my USB TV stick using UsbSnoop. I've been working together with David to make sure his lgs8gxx driver works with my TV stick, so yes, the generic driver actually works. :) Regards, Timothy Lee On 04/07/2009 01:44 AM, Mauro Carvalho Chehab wrote: On Tue, 31 Mar 2009 00:54:49 -0400 Devin Heitmuellerdevin.heitmuel...@gmail.com wrote: On Tue, Mar 17, 2009 at 11:55 AM, David Wongdavidtlw...@gmail.com wrote: This patch contains the unified driver for Legend Silicon LGS8913 and LGS8GL5. It should replace lgs8gl5.c in media/dvb/frontends David T.L. Wong David, The questions you posed tonight on a separate thread about making the xc5000 work with this device prompts the question: Do you know that this driver you submitted actually works? Have you successfully achieved lock with this driver and been able to view the stream? It is great to see the improvements and more generic support, but if you don't have it working in at least one device, then it probably shouldn't be submitted upstream yet, and it definitely should not be replacing an existing driver. We need to do some tests before replacing the existing one. Yet, it is better to have a generic device than specific ones. Do you have any card with lg8gl5? If so, could you please test the new driver for us? Anyway, I'm applying what we currently have. 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 -- 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: [GIT PATCHES for 2.6.30] V4L/DVB updates
On Mon, 6 Apr 2009 22:29:40 -0300 Mauro Carvalho Chehab mche...@redhat.com wrote: On Mon, 6 Apr 2009 18:11:34 -0700 (PDT) Linus Torvalds torva...@linux-foundation.org wrote: On Mon, 6 Apr 2009, Mauro Carvalho Chehab wrote: Please pull from: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git for_linus Have you rebased your tree and pushed out multiple versions of it? I'm getting very confusing things from the mirrors, which are subtly different from the copy on master. This all looks like it was rebased just hours ago, and to top it off, it looks like you actually change stuff you had exported earlier. Don't do that. Really. It's very annoying. More than annoying, in fact. This had better simply not happen again! Yes, unfortunately I had to rebase. I noticed that one of the patches were creating a file that didn't belong to that changeset, creating a file on the wrong place (at -p2 diff format). We should be discussing during this kernel cycle about migrating our development tree to use -git (instead of Mercurial). I hope that this will avoid to detect such errors so late, and avoid a few conversion issues we currently have. Sorry for the mess. In order to test, I did a fresh local clone of your tree and applied mine on the top of it. Everything worked as expected. Compilation also worked properly. I'll do my best to not rebase it anymore after exporting. Could you please pull from: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git for_linus -- 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] Support for Legend Silicon LGS8913/LGS8GL5/LGS8GXX China DMB-TH digital demodulator
On Tue, 07 Apr 2009 08:54:04 +0800 Timothy Lee timothy@siriushk.com wrote: Dear Mauro, I wrote the original lgs8gl5 driver by reverse-engineering my USB TV stick using UsbSnoop. I've been working together with David to make sure his lgs8gxx driver works with my TV stick, so yes, the generic driver actually works. :) Great! You should sign a patch together, removing the legacy module and using the newer one instead. It would be better to have this merged at the development tree for a while, to be sure that this won't cause regressions. 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] Anticipating lirc breakage
On Mon, 6 Apr 2009 17:44:48 +0200 Jean Delvare kh...@linux-fr.org wrote: Hi all, In the light of recent discussions and planed changes to the i2c subsystem and the ir-kbd-i2c driver, I will try to summarize the situation and make some proposals. Note that I am really not sure what we want to do, so this is a true request for opinions. First of all, the original reason for these changes is that I want to get rid of the legacy i2c binding model. As far as IR support is concerned, this means two things: * The ir-kbd-i2c driver must be converted to the new i2c binding model. I have been working on this already. * The removal of the legacy model will break lirc_i2c and possibly other lirc drivers. These will have to be converted to the new i2c binding model as well. While discussing my changes to ir-kbd-i2c, I received objections that these would adversely affect lirc users, and proposals were made to work around this problem, either by the means of module parameters, or by adding per-card logic in the bridge drivers. While this temporarily addresses the conflict with lirc, I feel like it is wasted energy because the second point is much more critical for lirc users. I'm going to remove the legacy i2c model pretty soon now and lirc_i2c and friends will have to be updated. This means two things: * There is no point in refining the ir-kbd-i2c conversion for users of the current lirc drivers, because the removal of the legacy i2c model will break these drivers a lot more anyway. * We need to come up with a strategy that makes it possible for lirc modules to still work afterwards. This is not trivial because the new i2c binding model makes life much harder for rogue/out-of-tree i2c drivers (note, this is just a side effect, the new model was not designed with this in mind.) The main technical problems I see as far as converting lirc to the new i2c binding model is concerned are: * Going the .detect() route is not as flexible as it was beforehand. In particular, having per-board probed address lists is no longer possible. It is possible to filter the addresses on a per-board basis after the fact, but the probes will still be issued for all addresses. I seem to remember that probing random addresses did cause trouble in the past on some boards, so I doubt we want to go that route. This is the reason why I decided to NOT go the .detect() route for ir-kbd-i2c conversion. * If we don't use .detect(), the bridge drivers must instantiate the devices themselves. That's what my ir-kbd-i2c patches do. One requirement is then that the bridge drivers and the chip drivers agree on the i2c device name(s). This was true for ir-kbd-i2c, it is true for lirc as well. Where it becomes difficult is that lirc lives outside of the kernel, while bridge drivers live inside the kernel. This will make the changes more difficult to synchronize. Probably a good incentive for lirc developers to merge their drivers into the kernel tree. While I think we all agree that lirc drivers should be merged in the kernel tree, it is pretty clear that it won't happen tomorrow. And, more importantly, it won't happen before I get rid of the legacy i2c binding model. So we need to come up with a design which makes it possible to keep using out-of-tree lirc drivers. It doesn't need to be perfect, but it has to somewhat work for now. My initial proposal made bridge drivers create ir-kbd [1] I2C devices for the ir-kbd-i2c driver to use. Mike Isely changed this in the pvrusb2 bridge driver to only instantiate the devices for boards on which ir-kbd-i2c is known to work. While this makes sense for the current situation (lirc_i2c is a legacy i2c driver) it will break as soon as lirc_i2c is converted to a new-style i2c driver: the converted lirc_i2c driver will need I2C devices to bind to, and the pvrusb2 driver won't create them. Same goes for cx18 boards, as Andy Walls and myself agreed to not create I2C devices for the IR receivers, because we know that ir-kbd-i2c doesn't support them. This made sense for the current situation, but the lirc_i2c conversion will break on these boards. And the same is also true for all board types where lirc_i2c (or other lirc modules for I2C IR receivers) support more devices than ir-kbd-i2c does: if the bridge drivers don't create the I2C devices, lirc_i2c won't have anything to bind to. The bottom line is that we have to instantiate I2C devices for IR components regardless of the driver which will handle them (ir-kbd-i2c, lirc_i2c or another one). I can think of two different strategies here: 1* Instantiate driver-neutral I2C devices, named for example ir_video. Let both ir-kbd-i2c and lirc_i2c (and possibly others) bind to them. The first loaded driver gets to bind to the device. This isn't so different from the current situation, the only difference being that the choice of
