Re: Mantis – anyone?
2009/11/26 Matthias Wächter : > I am now playing around with the available code for quite some time now > with mixed success, but no solution comes near the term “stable”. > > • kernel: nothing in there. Well, reasonable. > • v4l-dvb: nothing in there. > • s2-liplianin: mantis available, but obviously not under > development/bugfixing. IR seems to work, CI handling looks quite broken, > hangups/lockups are the rule, additional problems with more than one of > these cards in the system. > • mantis-v4l: does not compile out of the box for recent kernels. When > hand-knitting the files into a kernel source directory (2.6.31), works > quite unstable, module reloading frequently segfaults. IR does not work > (at least for VDR), CI handling looks better than s2-liplianin. > > Conclusion: Stability is way below a level for reasonable usage while > bug fixing. > > [1] gives an overview of the current state of (non-)development. Does > this still apply? > > My questions are: > > • Is there someone feeling responsible for that baby? > • What is the main part of the mantis stuff not working – mantis itself, > the frontend, or adaptions from multiproto to s2api? > • What can someone owning some of these cards (one Terratec, two > Technisat) do to help the (former) authors to continue their work? > • Is there some documentation available which would enable ‘the > community’ to work on that further? Please try http://jusst.de/hg/v4l-dvb and report the issues Regards, Manu -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Skystar HD2 and s2-liplianin/mantis driver
On Sun, Nov 29, 2009 at 7:31 PM, Albert Gall wrote: > Hello list > > I try to build latest s2-liplianin drivers but make shows severals > warnings and module not load after build driver: > > WARNING: "ir_input_keydown" [s2-liplianin/v4l/mantis.ko] undefined! > WARNING: "ir_codes_mantis_vp1041_table" [s2-liplianin/v4l/mantis.ko] > undefined! > WARNING: "ir_input_nokey" [s2-liplianin/v4l/mantis.ko] undefined! > WARNING: "ir_input_init" [s2-liplianin/v4l/mantis.ko] undefined! > WARNING: "ir_codes_mantis_vp2040_table" [s2-liplianin/v4l/mantis.ko] > undefined! > WARNING: "ir_codes_mantis_vp2033_table" [s2-liplianin/v4l/mantis.ko] > undefined! > > My kernel is 2.6.31.4. > The attached is full driver build log. > > Any idea to fix this problem ? Please try it from here: http://jusst.de/hg/v4l-dvb Regards, Manu -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Fri, Dec 4, 2009 at 8:48 PM, Andy Walls wrote: > On Fri, 2009-12-04 at 19:28 -0500, Jon Smirl wrote: >> On Fri, Dec 4, 2009 at 6:01 PM, Christoph Bartelmus >> wrote: >> > BTW, I just came across a XMP remote that seems to generate 3x64 bit scan >> > codes. Anyone here has docs on the XMP protocol? >> >> Assuming a general purpose receiver (not one with fixed hardware >> decoding), is it important for Linux to receive IR signals from all >> possible remotes no matter how old or obscure? > > Importance of any particular requirement is relative/subjective. As is > usefulness of any existing functionality. > > Personally, I just think it's cool to pick up a random remote and use > Linux to figure out its protocol and its codes and get it working. You are a technical user. > > > >> Or is it acceptable to >> tell the user to throw away their dedicated remote and buy a universal >> multi-function one? > > Nope. That other OS provider forces device obsolescence or arbitrary > constraints on users quite often and I don't like it myself. That's why > I use Linux. > > >> Universal multi-function remotes are $12 in my >> grocery store - I don't even have to go to an electronics store. > > The old remote in my possession costs $0, and I don't even have to leave > the house. > > >> I've been working off the premise of getting rid of obscure remotes >> and replacing them with a universal one. The universal one can be set >> to send a common protocol like JVC or Sony. That implies that we only >> need one or two protocol decoders in-kernel which greatly reduces the >> surface area of the problem. > > The design should serve the users, the users should not serve the > design. If the reduction of requirements scope starts forcing users to > buy new hardware, are we really serving the users or just asking them to > pay to compensate for our shortcomings? Use of arbitrary remotes is a complex process. It almost certainly can not be done in a transparent "just works" manner. Let me rephrase, is it ok to tell people to buy a new remote if they want to avoid a complex, technical configuration process that isn't even guaranteed to work (they might have a 56K remote and a 38K receiver or a Sony remote and a fixed RC-5 receiver). I'm not proposing that we prevent arbitrary remotes from working, you're just going to need to expend more effort to make them work. For example, you have to have a fair amount of IR knowledge to figure out why those two cases above don't work. You might have to install LIRC and futz with irrecord and build your own config files and mapping tables, etc... It doesn't have to only be a universal remote, we can pre-install mapping tables for the remotes commonly shipped with the v4l hardware. When the v4l drivers load they could even poke the default map for their bundled remotes directly into the input system if they wanted to. Doing that might save a lot of config issues. How this for new goals? Specific IR drivers autoload maps for their bundled remotes by poking them into the input subsystem during module load IR always has default map for a universal remote - it provides five devices and uses a common protocol like JVC (may not work for fixed hardware, you have to set these five common devices into the universal remote) All of these maps can be overriden with user space commands (which lets you configure funky remotes) -- Jon Smirl jonsm...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Fri, 2009-12-04 at 20:48 -0500, Andy Walls wrote: > On Fri, 2009-12-04 at 19:28 -0500, Jon Smirl wrote: > > On Fri, Dec 4, 2009 at 6:01 PM, Christoph Bartelmus > > wrote: > > > BTW, I just came across a XMP remote that seems to generate 3x64 bit scan > > > codes. Anyone here has docs on the XMP protocol? > > > > Assuming a general purpose receiver (not one with fixed hardware > > decoding), is it important for Linux to receive IR signals from all > > possible remotes no matter how old or obscure? Google reveals that XMP is somewhat new, proprietary, and not limited to remotes: http://www.uei.com/html.php?page_id=89 UEI is apparently the company responsible for the "One for All" brand of remote controls: http://www.uei.com/html.php?page_id=62 Here's some random tech details about one XMP remote: http://irtek.wikidot.com/remotecomcastxmp 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
mantis based cards and transponder 11303 on 19.2E
Hi ! After a change on Transponder 11303 on Astra 19.2 (adding of ORF HD) it is not longer possible to get a lock with mantis based cards. Users on vdrportal have reported that other cards do not have problems. All TT S2 3200 users ( like myself) are not able to get a lock on that transponder anymore. So "ServusTV HD" (one of the not to many HD freeview channels) is no longer accessible. I have tried recent liplianin drivers, and some old "multiproto_plus" drivers without success. Hope somebody can help. Peter -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Fri, 2009-12-04 at 19:28 -0500, Jon Smirl wrote: > On Fri, Dec 4, 2009 at 6:01 PM, Christoph Bartelmus wrote: > > BTW, I just came across a XMP remote that seems to generate 3x64 bit scan > > codes. Anyone here has docs on the XMP protocol? > > Assuming a general purpose receiver (not one with fixed hardware > decoding), is it important for Linux to receive IR signals from all > possible remotes no matter how old or obscure? Importance of any particular requirement is relative/subjective. As is usefulness of any existing functionality. Personally, I just think it's cool to pick up a random remote and use Linux to figure out its protocol and its codes and get it working. > Or is it acceptable to > tell the user to throw away their dedicated remote and buy a universal > multi-function one? Nope. That other OS provider forces device obsolescence or arbitrary constraints on users quite often and I don't like it myself. That's why I use Linux. > Universal multi-function remotes are $12 in my > grocery store - I don't even have to go to an electronics store. The old remote in my possession costs $0, and I don't even have to leave the house. > I've been working off the premise of getting rid of obscure remotes > and replacing them with a universal one. The universal one can be set > to send a common protocol like JVC or Sony. That implies that we only > need one or two protocol decoders in-kernel which greatly reduces the > surface area of the problem. The design should serve the users, the users should not serve the design. If the reduction of requirements scope starts forcing users to buy new hardware, are we really serving the users or just asking them to pay to compensate for our shortcomings? 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: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Fri, Dec 4, 2009 at 6:01 PM, Christoph Bartelmus wrote: > BTW, I just came across a XMP remote that seems to generate 3x64 bit scan > codes. Anyone here has docs on the XMP protocol? Assuming a general purpose receiver (not one with fixed hardware decoding), is it important for Linux to receive IR signals from all possible remotes no matter how old or obscure? Or is it acceptable to tell the user to throw away their dedicated remote and buy a universal multi-function one? Universal multi-function remotes are $12 in my grocery store - I don't even have to go to an electronics store. I've been working off the premise of getting rid of obscure remotes and replacing them with a universal one. The universal one can be set to send a common protocol like JVC or Sony. That implies that we only need one or two protocol decoders in-kernel which greatly reduces the surface area of the problem. >From my perspective Linux needs the capability to receive about 40 buttons on about five devices. How those 200 unique codes get into the box doesn't really matter so I was picking a simple protocol and setting the universal remote to support five devices in that protocol. Of course transmitting is a completely different problem, but we haven't been talking about transmitting. I can see how we would need to record any IR protocol in order to retransmit it. But that's in the 5% of users world, not the 90% that want MythTV to "just work". Use something like LIRC if you want to transmit. My goal was to make it simple for people to do really basic tasks like using a remote to pause their music player. Something like: plug in MSMCE receiver, program remote to send codes for Sony CR-114 mp3 player, hit pause button, music stops. -- Jon Smirl jonsm...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sound/usb: Relax urb data alignment restriciton for HVR-950Q only
On Fri, Dec 4, 2009 at 5:15 PM, John S Gruber wrote: > Addressing audio quality problem. > > In sound/usb/usbaudio.c, for the Hauppage HVR-950Q only, change > retire_capture_urb to copy the entire byte stream while still counting > entire audio frames. urbs unaligned on channel sample boundaries are > still truncated to the next lowest stride (audio slot) size to try to > retain channel alignment in cases of data loss over usb. > > With the HVR950Q the left and right channel samples can be split between > two different urbs. Throwing away extra channel samples causes a sound > quality problem for stereo streams as the left and right channels are > swapped repeatedly. Hello John, Thanks for taking the time to dig into this. I will try to review your patch this weekend (in conjunction with the spec). It's worth noting that there are actually nine different USB IDs that would need this change (see au0828-cards.c), so it might be nice to see if we can figure out a way for the au0828 driver to tell the usbaudio driver about the quirk without relying on embedding USB ids in the usbaudio driver. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Sat, Dec 05, 2009 at 12:01:00AM +0100, Christoph Bartelmus wrote: > Hi Dmitry, > > on 04 Dec 09 at 14:07, Dmitry Torokhov wrote: > > On Fri, Dec 04, 2009 at 10:46:00PM +0100, Christoph Bartelmus wrote: > >> Hi Mauro, > >> > >> on 04 Dec 09 at 12:33, Mauro Carvalho Chehab wrote: > >>> Christoph Bartelmus wrote: > >> Consider passing the decoded data through lirc_dev. > >> [...] > Consider cases like this: > http://lirc.sourceforge.net/remotes/lg/6711A20015N > > This is an air-conditioner remote. > The entries that you see in this config file are not really separate > buttons. Instead the remote just sends the current settings for e.g. > temperature encoded in the protocol when you press some up/down key. You > really don't want to map all possible temperature settings to KEY_* > events. For such cases it would be nice to have access at the raw scan > codes from user space to do interpretation of the data. > The default would still be to pass the data to the input layer, but it > won't hurt to have the possibility to access the raw data somehow. > >> > >>> Interesting. IMHO, the better would be to add an evdev ioctl to return the > >>> scancode for such cases, instead of returning the keycode. > >> > >> That means you would have to set up a pseudo keymap, so that you can get > >> the key event which you could than react on with a ioctl. Or are you > >> generating KEY_UNKNOWN for every scancode that is not mapped? > >> What if different scan codes are mapped to the same key event? How do you > >> retrieve the scan code for the key event? > >> I don't think it can work this way. > >> > > > EV_MSC/MSC_SCAN. > > How would I get the 64 bit scan codes that the iMON devices generate? > How would I know that the scan code is 64 bit? > input_event.value is __s32. > I suppose we could add MSC_SCAN_END event so that we can transmit "scancodes" of arbitrary length. You'd get several MSC_SCAN followed by MSC_SCAN_END marker. If you don't get MSC_SCAN_END assume the code is 32 bit. FWIW there is MSC_RAW as well. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH - v0 2/2] DaVinci - vpfe capture - Make clocks configurable
Vaibhav,
Could you confirm my question below? I need to submit a patch on Monday.
>>Currently we have vpfe_capture.c file (master/bridge driver) which is
>>handling clk_get/put, and platform data is providing the details about it.
>>Ideally we should handle it in respective ccdc driver file, since he has
>>all the knowledge about required number of clocks and its name. This way
>we
>>don't have to maintain/pass clock information in platform data.
>>
>>I would appreciate any comments/thoughts/pointers here.
>>
>Though I agree that this clock could be set by the ccdc driver, I am not
>sure if the same clock is used by an IP on different SOCs. For example take
>the case of ccdc on DM6446 which is also used on OMAP 35xx SOC. Do they use
>vpss master and slave clocks as is done on DM6446? If this is true, then we
>could set the clock inside ccdc driver.
>
>Let me know so that I can re-work the patch and send it to the list.
>
>Murali
>>Thanks,
>>Vaibhav
>>
>>> };
>>>
>>> static struct platform_device *davinci_evm_devices[] __initdata = {
>>> diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c
>>> b/arch/arm/mach-davinci/board-dm644x-evm.c
>>> index fd0398b..45beb99 100644
>>> --- a/arch/arm/mach-davinci/board-dm644x-evm.c
>>> +++ b/arch/arm/mach-davinci/board-dm644x-evm.c
>>> @@ -250,6 +250,8 @@ static struct vpfe_config vpfe_cfg = {
>>> .sub_devs = vpfe_sub_devs,
>>> .card_name = "DM6446 EVM",
>>> .ccdc = "DM6446 CCDC",
>>> + .num_clocks = 2,
>>> + .clocks = {"vpss_master", "vpss_slave"},
>>> };
>>>
>>> static struct platform_device rtc_dev = {
>>> --
>>> 1.6.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v0 1/2] V4L - vpfe capture - convert ccdc drivers to platform drivers
Sekhar, >> >> + status = -EBUSY; >> >[Hiremath, Vaibhav] Is -EBUSY right return value, I think it should be - >> >ENXIO or -ENOMEM. >> > >> I see -ENXIO & -ENOMEM being used by drivers. -ENXIO stands for "No such >device or address". ENOMEM stands for "Out of memory" . Since we are trying >to map the address here, -ENXIO looks reasonable to me. Same if >request_mem_region() fails. >> > >Sergei had posted on this earlier[1]. Quoting him here: Was this his personal opinion or has he given any reference to support it? I did a grep for this in the driver directory and the result I got is in inline with Sergie's suggestion. So I am going to update the patch with these and send it again. -Murali > >" >> What are the proper error codes when platform_get_resource, > >-ENODEV. > >> request_mem_region > >-EBUSY. > >> and ioremap functions fail?. > >-ENOMEM. >" > >Not sure if ioremap failure can relate to absence of a device. > >Thanks, >Sekhar > >[1] http://www.mail-archive.com/davinci-linux-open- >sou...@linux.davincidsp.com/msg14973.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: [RFC] What are the goals for the architecture of an in-kernel IR system?
Hi Dmitry, on 04 Dec 09 at 14:07, Dmitry Torokhov wrote: > On Fri, Dec 04, 2009 at 10:46:00PM +0100, Christoph Bartelmus wrote: >> Hi Mauro, >> >> on 04 Dec 09 at 12:33, Mauro Carvalho Chehab wrote: >>> Christoph Bartelmus wrote: >> Consider passing the decoded data through lirc_dev. >> [...] Consider cases like this: http://lirc.sourceforge.net/remotes/lg/6711A20015N This is an air-conditioner remote. The entries that you see in this config file are not really separate buttons. Instead the remote just sends the current settings for e.g. temperature encoded in the protocol when you press some up/down key. You really don't want to map all possible temperature settings to KEY_* events. For such cases it would be nice to have access at the raw scan codes from user space to do interpretation of the data. The default would still be to pass the data to the input layer, but it won't hurt to have the possibility to access the raw data somehow. >> >>> Interesting. IMHO, the better would be to add an evdev ioctl to return the >>> scancode for such cases, instead of returning the keycode. >> >> That means you would have to set up a pseudo keymap, so that you can get >> the key event which you could than react on with a ioctl. Or are you >> generating KEY_UNKNOWN for every scancode that is not mapped? >> What if different scan codes are mapped to the same key event? How do you >> retrieve the scan code for the key event? >> I don't think it can work this way. >> > EV_MSC/MSC_SCAN. How would I get the 64 bit scan codes that the iMON devices generate? How would I know that the scan code is 64 bit? input_event.value is __s32. BTW, I just came across a XMP remote that seems to generate 3x64 bit scan codes. Anyone here has docs on the XMP protocol? Christoph -- 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] sound/usb: Relax urb data alignment restriciton for HVR-950Q only
Addressing audio quality problem.
In sound/usb/usbaudio.c, for the Hauppage HVR-950Q only, change
retire_capture_urb to copy the entire byte stream while still counting
entire audio frames. urbs unaligned on channel sample boundaries are
still truncated to the next lowest stride (audio slot) size to try to
retain channel alignment in cases of data loss over usb.
With the HVR950Q the left and right channel samples can be split between
two different urbs. Throwing away extra channel samples causes a sound
quality problem for stereo streams as the left and right channels are
swapped repeatedly.
modified: sound/usb/usbaudio.c
Signed-off-by: John S. Gruber
---
sound/usb/usbaudio.c | 45 +++--
1 files changed, 35 insertions(+), 10 deletions(-)
diff --git a/sound/usb/usbaudio.c b/sound/usb/usbaudio.c
index 44b9cdc..64d9d3a 100644
--- a/sound/usb/usbaudio.c
+++ b/sound/usb/usbaudio.c
@@ -107,8 +107,9 @@ MODULE_PARM_DESC(ignore_ctl_error,
#define MAX_PACKS_HS (MAX_PACKS * 8) /* in high speed mode */
#define MAX_URBS 8
#define SYNC_URBS 4 /* always four urbs for sync */
#define MAX_QUEUE 24 /* try not to exceed this queue length, in ms */
+#define ALLOW_SUBSLOT_BOUNDARIES 0x01 /* quirk */
struct audioformat {
struct list_head list;
snd_pcm_format_t format;/* format type */
@@ -126,8 +127,9 @@ struct audioformat {
unsigned int rates; /* rate bitmasks */
unsigned int rate_min, rate_max;/* min/max rates */
unsigned int nr_rates; /* number of rate table entries */
unsigned int *rate_table; /* rate table */
+ unsigned int txfr_quirks; /* transfer quirks */
};
struct snd_usb_substream;
@@ -174,8 +176,11 @@ struct snd_usb_substream {
unsigned int running: 1;/* running status */
unsigned int hwptr_done;/* processed frame
position in the buffer */
+ unsigned int byteptr; /* position, in bytes, of next move */
+ unsigned int remainder; /* extra bytes moved to buffer */
+ unsigned int txfr_quirks; /* substream transfer quirks */
unsigned int transfer_done; /* processed frames since last
period update */
unsigned long active_mask; /* bitmask of active urbs */
unsigned long unlink_mask; /* bitmask of unlinked urbs */
@@ -342,9 +347,9 @@ static int retire_capture_urb(struct
snd_usb_substream *subs,
{
unsigned long flags;
unsigned char *cp;
int i;
- unsigned int stride, len, oldptr;
+ unsigned int stride, len, bytelen, oldbyteptr;
int period_elapsed = 0;
stride = runtime->frame_bits >> 3;
@@ -353,31 +358,44 @@ static int retire_capture_urb(struct
snd_usb_substream *subs,
if (urb->iso_frame_desc[i].status) {
snd_printd(KERN_ERR "frame %d active: %d\n", i,
urb->iso_frame_desc[i].status);
// continue;
}
- len = urb->iso_frame_desc[i].actual_length / stride;
- if (! len)
+ bytelen = (urb->iso_frame_desc[i].actual_length);
+ if (!bytelen)
continue;
+ if (!(subs->txfr_quirks & ALLOW_SUBSLOT_BOUNDARIES))
+ bytelen = (bytelen/stride)*stride;
+ if (bytelen%(runtime->sample_bits>>3) != 0) {
+ int oldbytelen = bytelen;
+ bytelen = ((bytelen/stride)*stride);
+ printk(KERN_DEBUG "Corrected urb data len. %d -> %d\n",
+ oldbytelen, bytelen);
+ }
/* update the current pointer */
spin_lock_irqsave(&subs->lock, flags);
- oldptr = subs->hwptr_done;
+ len = (bytelen + subs->remainder) / stride;
+ subs->remainder = (bytelen + subs->remainder) % stride;
+ oldbyteptr = subs->byteptr;
subs->hwptr_done += len;
if (subs->hwptr_done >= runtime->buffer_size)
subs->hwptr_done -= runtime->buffer_size;
subs->transfer_done += len;
if (subs->transfer_done >= runtime->period_size) {
subs->transfer_done -= runtime->period_size;
period_elapsed = 1;
}
+ subs->byteptr += bytelen;
+ if (subs->byteptr >= runtime->buffer_size*stride)
+ subs->byteptr -= runtime->buffer_size*stride;
spin_unlock_irqrestore(&subs->lock, flags);
/* copy a data chunk */
- if (oldptr + len > runtime->buffer_size) {
- unsigned int cnt = runtime->buffer_size - oldptr;
- unsigned int blen = cnt * stride;
-
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Fri, Dec 04, 2009 at 10:46:00PM +0100, Christoph Bartelmus wrote: > Hi Mauro, > > on 04 Dec 09 at 12:33, Mauro Carvalho Chehab wrote: > > Christoph Bartelmus wrote: > Consider passing the decoded data through lirc_dev. > [...] > >> Consider cases like this: > >> http://lirc.sourceforge.net/remotes/lg/6711A20015N > >> > >> This is an air-conditioner remote. > >> The entries that you see in this config file are not really separate > >> buttons. Instead the remote just sends the current settings for e.g. > >> temperature encoded in the protocol when you press some up/down key. You > >> really don't want to map all possible temperature settings to KEY_* > >> events. For such cases it would be nice to have access at the raw scan > >> codes from user space to do interpretation of the data. > >> The default would still be to pass the data to the input layer, but it > >> won't hurt to have the possibility to access the raw data somehow. > > > Interesting. IMHO, the better would be to add an evdev ioctl to return the > > scancode for such cases, instead of returning the keycode. > > That means you would have to set up a pseudo keymap, so that you can get > the key event which you could than react on with a ioctl. Or are you > generating KEY_UNKNOWN for every scancode that is not mapped? > What if different scan codes are mapped to the same key event? How do you > retrieve the scan code for the key event? > I don't think it can work this way. > EV_MSC/MSC_SCAN. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next i386 allmodconfig
Randy Dunlap wrote: > On Thu, 3 Dec 2009 22:57:37 -0800 Andrew Morton wrote: > >> ERROR: "__divdf3" [drivers/media/dvb/frontends/atbm8830.ko] undefined! >> ERROR: "__adddf3" [drivers/media/dvb/frontends/atbm8830.ko] undefined! >> ERROR: "__fixunsdfsi" [drivers/media/dvb/frontends/atbm8830.ko] undefined! >> ERROR: "__udivdi3" [drivers/media/dvb/frontends/atbm8830.ko] undefined! >> ERROR: "__floatsidf" [drivers/media/dvb/frontends/atbm8830.ko] undefined! >> ERROR: "__muldf3" [drivers/media/dvb/frontends/atbm8830.ko] undefined! >> ERROR: "__adddf3" [drivers/media/common/tuners/max2165.ko] undefined! >> ERROR: "__fixunsdfsi" [drivers/media/common/tuners/max2165.ko] undefined! >> ERROR: "__floatsidf" [drivers/media/common/tuners/max2165.ko] undefined! >> >> would be nice to get that fixed up before merging. >> -- > > Already reported and patches sent to me & tested/acked. I've merged it on my linux-next tree today. Cheers, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Hi Mauro, on 04 Dec 09 at 12:33, Mauro Carvalho Chehab wrote: > Christoph Bartelmus wrote: Consider passing the decoded data through lirc_dev. [...] >> Consider cases like this: >> http://lirc.sourceforge.net/remotes/lg/6711A20015N >> >> This is an air-conditioner remote. >> The entries that you see in this config file are not really separate >> buttons. Instead the remote just sends the current settings for e.g. >> temperature encoded in the protocol when you press some up/down key. You >> really don't want to map all possible temperature settings to KEY_* >> events. For such cases it would be nice to have access at the raw scan >> codes from user space to do interpretation of the data. >> The default would still be to pass the data to the input layer, but it >> won't hurt to have the possibility to access the raw data somehow. > Interesting. IMHO, the better would be to add an evdev ioctl to return the > scancode for such cases, instead of returning the keycode. That means you would have to set up a pseudo keymap, so that you can get the key event which you could than react on with a ioctl. Or are you generating KEY_UNKNOWN for every scancode that is not mapped? What if different scan codes are mapped to the same key event? How do you retrieve the scan code for the key event? I don't think it can work this way. Christoph -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppage hvr-950q au0828 transfer problem affecting audio and perhaps video
On Fri, Dec 4, 2009 at 10:43 AM, Devin Heitmueller wrote: > On Fri, Dec 4, 2009 at 9:31 AM, John S Gruber wrote: >> I produced the dump of URB sizes you requested by adding that printk() line. >> The >> results are at http://pastebin.com/f26f29133 > > Hi John, > > This is good info (especially since you have kernel timestamps enabled). > > Did you have a specific reference to the USB audio spec which said the > packet size has to be on an integer boundary? I took a look at the > spec last night and didn't see anything to that end. > > Do you have a proposed patch to usbaudio.c which "works for you"? If > so, feel free to send it along and I will review and provide comments. > If the spec does not require the packets to be on an integer > boundary, perhaps the driver just improperly assumes they will be (and > they were for whatever developer wrote the original code). > > Devin > > -- > Devin J. Heitmueller - Kernel Labs > http://www.kernellabs.com > Hi Devin, You might look at this: http://www.usb.org/developers/devclass_docs/Audio2.0_final.zip File: Frmts20 final.pdf Sections 2.3.1.3, 2.3.1.4 and 2.3.1.5 on page 15 This is from release 2.0 from 5/31/2006 Also http://www.usb.org/developers/devclass_docs/frmts10.pdf Sections 2.2.2, 2.2.3 and 2.2.4 on page 9. This is the 1998 1.0 release. Thanks for your offer to review my patch. I'll try to post it yet today. I'm still messing around with it. -- 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: Details about DVB frontend API
On Fri, Dec 4, 2009 at 3:02 PM, VDR User wrote: > No activity in this thread for 2 weeks now. Has there been any progress? I think I speak on behalf of most LinuxTV developers, when I say that nobody wants to spend their free personal time working on something that might get shot down with such controversy. I have stated that I like Manu's proposal, but I would prefer that the get_property (s2api) interface were used, because it totally provides an interface that is sufficient for this feature. Manu and I agree that these values should all be read at once. I think we all (except Mauro) agree that the behavior within the driver should fetch all statistics at once and return it to userspace as a single structure with all the information as it all relates to each other. Furthermore, I think we all know that we cant just remove the current structures, and we should do something to normalize the current reporting values. The longer this thread gets, the less likely anybody is to do anything about it. Let me state my opinion again: I would like to see a solution merged, and I think Manu's solution is reasonable, although it may be complicated -- if all drivers are updated to support it, then it will all be worth it. The question is, *will* all drivers update to support this? I don't know. We have the S2API's set / get property API -- In my opinion, we should use this API to fetch statistic information and have it return a single atomic structure. Applications can use only the information that they're interested in. In the meanwhile, as a SEPARATE PROJECT, we should do something to standardize the values reported by the CURRENT API across the entire subsystem. This should not be confused with Manu's initiative to create a better API -- we cant remove the current API, but it should be standardized. I volunteer to work on the standardization of the CURRENT Api, and I am all for seeing a new API introduced for better statistical reporting, provided that the get property method is used as an interface, rather than adding new ioctls. However, if we add a new API, we haev to make sure that all the current drivers are updated to support it -- do we have all the information that we need for this? Do we have the manpower and the drive to get it done? My urge to do this work is a strong urge, but I have no desire to do this if people want to continue arguing about it... In the meanwhile, I am working on new drivers for new devices, and this is *much* more interesting that worrying about how strong a signal is for a device that already works. When you folks stop talking about this, that's when I will push the trees containing all the work that I've done already thus far -- we need to standardize the current API, and that has nothing to do with Manu's proposal. We should not confuse standardization the current reporting units with the introduction of a new API -- both should be done, but the more arguing there is about it, the less of a chance that anybody will volunteer their own time to work on it. ...and just to clarify -- I think I said it twice already, but repeating again -- I (mostly) like Manu's proposal, but if we cant update the drivers to support it, then is it worth the trouble? Regards, Mike Krufky -- 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: Details about DVB frontend API
No activity in this thread for 2 weeks now. Has there been any progress? Regards. -- 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:Fri Dec 4 19:00:05 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13538:e0cd9a337600 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.30-armv5: OK linux-2.6.31-armv5: OK linux-2.6.32-armv5: OK linux-2.6.32-armv5-davinci: OK linux-2.6.30-armv5-ixp: OK linux-2.6.31-armv5-ixp: OK linux-2.6.32-armv5-ixp: OK linux-2.6.30-armv5-omap2: OK linux-2.6.31-armv5-omap2: OK linux-2.6.32-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.1-i686: WARNINGS linux-2.6.30-i686: OK linux-2.6.31-i686: OK linux-2.6.32-i686: OK linux-2.6.30-m32r: OK linux-2.6.31-m32r: OK linux-2.6.32-m32r: OK linux-2.6.30-mips: OK linux-2.6.31-mips: OK linux-2.6.32-mips: OK linux-2.6.30-powerpc64: OK linux-2.6.31-powerpc64: OK linux-2.6.32-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.1-x86_64: WARNINGS linux-2.6.30-x86_64: OK linux-2.6.31-x86_64: OK linux-2.6.32-x86_64: OK spec: OK sparse (linux-2.6.32): ERRORS linux-2.6.16.61-i686: WARNINGS linux-2.6.17.14-i686: WARNINGS linux-2.6.18.8-i686: WARNINGS linux-2.6.19.5-i686: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.16.61-x86_64: WARNINGS linux-2.6.17.14-x86_64: WARNINGS linux-2.6.18.8-x86_64: WARNINGS linux-2.6.19.5-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next i386 allmodconfig
Randy Dunlap wrote: > On Thu, 3 Dec 2009 22:57:37 -0800 Andrew Morton wrote: > >> ERROR: "__divdf3" [drivers/media/dvb/frontends/atbm8830.ko] undefined! >> ERROR: "__adddf3" [drivers/media/dvb/frontends/atbm8830.ko] undefined! >> ERROR: "__fixunsdfsi" [drivers/media/dvb/frontends/atbm8830.ko] undefined! >> ERROR: "__udivdi3" [drivers/media/dvb/frontends/atbm8830.ko] undefined! >> ERROR: "__floatsidf" [drivers/media/dvb/frontends/atbm8830.ko] undefined! >> ERROR: "__muldf3" [drivers/media/dvb/frontends/atbm8830.ko] undefined! >> ERROR: "__adddf3" [drivers/media/common/tuners/max2165.ko] undefined! >> ERROR: "__fixunsdfsi" [drivers/media/common/tuners/max2165.ko] undefined! >> ERROR: "__floatsidf" [drivers/media/common/tuners/max2165.ko] undefined! >> >> would be nice to get that fixed up before merging. >> -- > > Already reported and patches sent to me & tested/acked. I should be adding it at linux-next later today. 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: af9015: tuner id:179 not supported, please report!
On Thu, Dec 3, 2009 at 5:03 PM, Devin Heitmueller wrote: > On Thu, Dec 3, 2009 at 4:47 PM, Bert Massop wrote: >> Hi Jan, >> >> The datasheet for the TDA18218 can be obtained from NXP: >> http://www.nxp.com/documents/data_sheet/TDA18218HN.pdf >> >> That's all the information I have at the moment, maybe Mike has some >> other information (like the Application Note mentioned in the >> datasheet, that claims to contain information on writing drivers, but >> cannot be found anywhere). >> >> Best regards, >> >> Bert > > Took a quick look at that datasheet. I would guess between that > datasheet and a usbsnoop, there is probably enough there to write a > driver that basically works for your particular hardware if you know > what you are doing. The register map is abbreviated, but probably > good enough... > > Devin The datasheet is missing too much important information needed to write a fully featured driver for the part, and I wouldn't recommend using a usbsnoop for this type of tuner, but be my guest and prove me wrong. You might be able to get it working, but you'll end up with tons of binary blobs hardcoded for each frequency, unless you use a programming guide. Unfortunately, I don't have one that I can share :-/ I think you would be much better off purchasing supported hardware, instead. Good luck, though... -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
PULL request - http://linuxtv.org/hg/~pb/v4l-dvb/
Hi Mauro, please pull from http://linuxtv.org/hg/~pb/v4l-dvb/ for the following changeset: DiB8090: Add the DiB0090 tuner driver and STK8096GP-board This is the adding support for the DiB809x-device you were asking 2 weeks ago. If possible, please include it into the patches which will go for 2.6.33 . This repo also includes the changesets which were in my previous pull request. thanks, Patrick. -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ -- 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-next i386 allmodconfig
On Thu, 3 Dec 2009 22:57:37 -0800 Andrew Morton wrote: > ERROR: "__divdf3" [drivers/media/dvb/frontends/atbm8830.ko] undefined! > ERROR: "__adddf3" [drivers/media/dvb/frontends/atbm8830.ko] undefined! > ERROR: "__fixunsdfsi" [drivers/media/dvb/frontends/atbm8830.ko] undefined! > ERROR: "__udivdi3" [drivers/media/dvb/frontends/atbm8830.ko] undefined! > ERROR: "__floatsidf" [drivers/media/dvb/frontends/atbm8830.ko] undefined! > ERROR: "__muldf3" [drivers/media/dvb/frontends/atbm8830.ko] undefined! > ERROR: "__adddf3" [drivers/media/common/tuners/max2165.ko] undefined! > ERROR: "__fixunsdfsi" [drivers/media/common/tuners/max2165.ko] undefined! > ERROR: "__floatsidf" [drivers/media/common/tuners/max2165.ko] undefined! > > would be nice to get that fixed up before merging. > -- Already reported and patches sent to me & tested/acked. --- ~Randy -- 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 v2] Another approach to IR
Dmitry Torokhov writes: > On Thu, Dec 03, 2009 at 02:33:56PM -0200, Mauro Carvalho Chehab wrote: >> Ferenc Wagner wrote: >>> Mauro Carvalho Chehab writes: >> >> We should not forget that simple IR's don't have any key to select the >> address, >> so the produced codes there will never have KEY_TV/KEY_DVD, etc. > > Wait, wait, KEY_TV, KEY_DVD, KEY_TAPE - they should be used to select > media inputs in a device/application. My receiver accepts codes like > that. Sorry, my point wasn't the event names, I picked them for their superficial correspondence to the TV, DVD, SAT etc. buttons found on multifunction remotes. Obviously I picked wrong. I was also wrong to assume that remotes with such buttons are always multifunction remotes in the sense that they are meant to control separate devices. As Mauro pointed out, (some) bundled remotes with such buttons aren't; thus I wouldn't consider them multifunction at all. They simply have some extra buttons labelled TV, DVD etc, which probably shouldn't be mapped to KEY_TV, KEY_DVD etc. (since those events carry different semantics) but should be mapped to something else. Or not, if these buttons change some internal decoder state instead, modifying the mapping or destination input device of the other keys. It's just a different scenario, where the kernel could reasonably give rather different representations to simple applications aiming at plug&play: letting through the function change events untouched, or masking and using them internally. True multifunction devices don't send such events, the TV, DVD etc buttons on them change their internal state and the scan codes sent by the other keys, if I understand this correctly. I'd prefer if these two behaviours could be abstacted from, and the input layer interface would provide destination selection events + generic events, or (to be defined) device specific events only in either case. Is that possible or even reasonable? -- Thanks, Feri. Ps: I'm writing this in the hope to clean up the landscape and possibly help in choosing the best design. I'm not at all familiar with IR, and the above distinction was pretty surprising for me. Also, I'm just lurking here, so don't take me too seriously. :) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppage hvr-950q au0828 transfer problem affecting audio and perhaps video
On Fri, Dec 4, 2009 at 9:31 AM, John S Gruber wrote: > I produced the dump of URB sizes you requested by adding that printk() line. > The > results are at http://pastebin.com/f26f29133 Hi John, This is good info (especially since you have kernel timestamps enabled). Did you have a specific reference to the USB audio spec which said the packet size has to be on an integer boundary? I took a look at the spec last night and didn't see anything to that end. Do you have a proposed patch to usbaudio.c which "works for you"? If so, feel free to send it along and I will review and provide comments. If the spec does not require the packets to be on an integer boundary, perhaps the driver just improperly assumes they will be (and they were for whatever developer wrote the original code). Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Fri, Dec 4, 2009 at 9:12 AM, Mauro Carvalho Chehab wrote: >> In-kernel decoding: >> [IR physical device] => [IR receiver driver] => [LIRC core] => [decoder] => [IR core] => [input core] => [evdev] || => [Lirc API device]>> >> Hardware decoder: >> [IR physical device] => [IR receiver driver] => [IR core] >> => [input core] => [evdev] My hope is that 90% of users can achieve "just works" via these two models. There will need to be several default device/keymaps installed to avoid the need to configure. For example, have udev install a default map from Motorola DVR IR to Linux keycodes. Installing that map creates a new evdev device. Myth can then look for that device by default and listen to it. Now the user just needs to set their programmable remote to send Motorola DVR and everything should "just work". Pick similar default maps/evdev device for music players and home automation. Sophisticated users can change these default maps by editing the udev scripts. Long term the goal is to get IR profiles for Linux DVR, music player, home automation, etc in to the IR database. Then we won't have to override the profile for another company's device. I believe it is a requirement to send the decoded IR events up to user space (EV_IR). That would handle the case of the air conditioner remote. It also allows construction of an app that automatically searches the IR database for mapping tables. Normal apps would just ignore these events. Installing a map is what triggers the creation of another evdev device. There should be one evdev device per map installed. The current input API design does not provide for a way to do this. The only solution I see to automatic device creation is to monitor unmapped EV_IR events and search for them in the IR database. When a match is found, install the map from the database - which then triggers the creation of a new evdev device and the EV_IR event won't be unmapped any more. Searching is not a simple process since the same IR code often appears in more than one map. Some human intervention will probably be required. [IR physical device] => [IR receiver driver] => [LIRC core] => [decoder] => [IR core] => [input core] => [evdev] || || => [Lirc API device] ==> [EV_IR events] The EV_IR events also allow a user space protocol decoder to inject those events back into the input subsystem where they will flow through the mapping tables. The in-kernel protocol decoders should be designed as a set of modules with the pulse data being simultaneously supplied to all modules. That will make it easy to work on the protocol converters - just insmod/rmmod as you make changes. These engines can be extracted from the LIRC code and turned into modules. Where are IR repeat bits going to be handled? -- Jon Smirl jonsm...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] V4L - Fix videobuf_dma_contig_user_get() getting page aligned physical address
Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com >-Original Message- >From: Magnus Damm [mailto:magnus.d...@gmail.com] >Sent: Friday, December 04, 2009 6:06 AM >To: Karicheri, Muralidharan >Cc: linux-media@vger.kernel.org; mche...@infradead.org; davinci-linux-open- >sou...@linux.davincidsp.com >Subject: Re: [PATCH] V4L - Fix videobuf_dma_contig_user_get() getting page >aligned physical address > >Hi again Murali, > >Thanks for your work on this. > >On Thu, Dec 3, 2009 at 12:48 AM, Karicheri, Muralidharan > wrote: >> Magnus, >> >>>Thanks for the patch. For non-page aligned user space pointers I agree >>>that a fix is needed. Don't you think the while loop in >>>videobuf_dma_contig_user_get() also needs to be adjusted to include >>>the last page? I think the while loop checks one page too little in >>>the non-aligned case today. >> >> Thanks for reviewing my patch. It had worked for non-aligned address in >> my testing. If I understand this code correctly, the physical address of >> the user page start is determined in the first loop (pages_done == 0) >> and additional loops are run to make sure the memory is physically >> contiguous. Initially the mem->size is set to number of pages aligned to >> page size. >> >> Assume we pass 4097 bytes as size. >> >> mem->size = PAGE_ALIGN(vb->size); => 2 >> >> Inside the loop, iteration is done for 0 to pages-1. >> >> pages_done < (mem->size >> 12) => pages_done < 2 => iterate 2 times >> >> For size of 4096, we iterate once. >> For size of 4095, we iterate once. >> >> So IMO the loop is already iterate one more time when we pass non-aligned >address since size is aligned to include the last page. So based on this >> could you ack my patch so that we could ask Mauro to merge it with >priority? > >I think your observations are correct, but I also think there is one >more hidden issue. In the case where the offset within the page is >other than 0 then we should loop once more to also check the final >page. Right now no one is checking if the last page is contiguous or >not in the case on non-page-aligned offset.. > >So in your case with a 4096 or 4095 size, but if the offset withing >the page is non-zero then we should loop twice to make sure the pages >really are physically contiguous. Today we only loop once based on the >size. We should also include the offset in the calculation of number >of pages to check. Yes. You are right. For offsets that are non-aligned we need to check for the last one. Probably unsigned int offset = vb->baddr & ~PAGE_MASK; mem->size = PAGE_ALIGN(vb->size + offset); .. if (pages_done == 0) mem->handle = (this_pfn << PAGE_SHIFT) + offset; If this is fine, I can send you a updated patch. If you can fix it that is fine too. regards, Murali > >If you can include that fix in your patch that would be great. If not >then i'll fix it up myself. > If you could do this it will be great! >Thanks! > >/ magnus -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Christoph Bartelmus wrote: > Hi Dmitry, > > on 03 Dec 09 at 14:12, Dmitry Torokhov wrote: > [...] >>> Consider passing the decoded data through lirc_dev. > [...] >> I believe it was agreed that lirc-dev should be used mainly for decoding >> protocols that are more conveniently decoded in userspace and the >> results would be looped back into input layer through evdev which will >> be the main interface for consumer applications to use. > > Quoting myself: >> Currently I would tend to an approach like this: >> - raw interface to userspace using LIRC > > For me this includes both the pulse/space data and also the scan codes > when hardware does the decoding. > Consider cases like this: > http://lirc.sourceforge.net/remotes/lg/6711A20015N > > This is an air-conditioner remote. > The entries that you see in this config file are not really separate > buttons. Instead the remote just sends the current settings for e.g. > temperature encoded in the protocol when you press some up/down key. You > really don't want to map all possible temperature settings to KEY_* > events. For such cases it would be nice to have access at the raw scan > codes from user space to do interpretation of the data. > The default would still be to pass the data to the input layer, but it > won't hurt to have the possibility to access the raw data somehow. Interesting. IMHO, the better would be to add an evdev ioctl to return the scancode for such cases, instead of returning the keycode. Cheers, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppage hvr-950q au0828 transfer problem affecting audio and perhaps video
> I am definitely seeing what you are saying with regards to the channel > flipping back and forth. Do you know what size URBs are being > delivered? If you've got a hacked up version of usbaudio.c, how about > adding a printk() line which dumps out the URB size and send me a > dump? > > Devin > > -- > Devin J. Heitmueller - Kernel Labs > http://www.kernellabs.com > I produced the dump of URB sizes you requested by adding that printk() line. The results are at http://pastebin.com/f26f29133 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Em Fri, 4 Dec 2009 02:06:42 -0800 Dmitry Torokhov escreveu: > On Thu, Dec 03, 2009 at 04:33:28PM -0200, Mauro Carvalho Chehab wrote: > > Let me draw my view: > > > > Em Thu, 3 Dec 2009 09:55:31 -0800 > > Dmitry Torokhov escreveu: > > > > > No, please, wait just a minute. I know it is tempting to just merge > > > lirc_dev and start working, but can we first agree on the overall > > > subsystem structure before doing so. It is still quite inclear to me. > > > > > > The open questions (for me at least): > > > > > > - do we create a new class infrastructure for all receivers or only for > > > ones plugged into lirc_dev? Remember that classifying objects affects > > > how udev and friemds see them and may either help or hurt writing PnP > > > rules. > > > > IMO, I would create it as /sys/class/input/IR (just like the /mice). I > > That will not work. Driver core does not support notion of subclasses, > Greg and Kay insist on flat class namespace. Mice do not belong to a > separate [sub]class, they all members of input class, with peculiar > directory structure. > > IRs however, I believe, deserve a full-fledged class (since they are in > my view are parents to the input devices representing remotes). I would > argus for the following sysfs hierarchy for the main device tree: > > /sys/devices/pcipci:00/../pci.../../irrcv0/input14/event16 > /sys/devices/pcipci:00/../usb.../../irrcv1/input15/event17 > /input16/event18 > > And corresponding class: > > /sys/class/irrcv/irrcv0 > irrcv1 > > and so on. Seems fine to me. > > > > > don't see why do we need to different lirc than no-lirc drivers in the > > case of sysfs class. > > I do agree that _all_ infrared receivers should belong to this class, > and not only ones utilizing lirc_dev. > > > As devices with raw input capabilities will have > > another dev to communicate, this means that we'll need a /lirc node > > there to point to lirc dev. > > > > > > > > - do we intend to support in-kernel sotfware decoders? > > > > Yes. > > > > Good. > > > > - What is the structure? Do we organize them as a module to be used by > > > driver > > > directly or the driver "streams" the data to IR core and the core > > > applies decoders (in the same fashion input events from drivers flow > > > into input core and then distributed to all bound interfaces for > > > processing/conversion/transmission to userspace)? > > > > My plan is to expand ir-common.ko module and rename it to ir-core, to be > > the IR core module for the evdev interface. I'm already working on it. > > My idea for an architecture is that the lirc-core module will use > > ir-common where the IR decoders will be, and the evdev interface. > > > > How related lirc-core to the current lirc code? If it is not the same > maybe we should not call it lirc to avoid confusion. Just for better illustrate what I'm seeing, I broke the IR generic code into two components: lirc core - the module that receives raw pulse/space and creates a device to receive raw API pulse/space events; IR core - the module that receives scancodes, convert them into keycodes and send via evdev interface. We may change latter the nomenclature, but I'm seeing the core as two different modules, since there are cases where lirc core won't be used (those devices were there's no way to get pulse/space events). > > Not sure if I got your idea. Basically, what I see is: > > > > For device drivers that work in raw mode: > > [IR physical device] ==> [IR receiver driver] ==> [lirc-core] ==> > > [decoder] ==> [ir-core] ==> [evdev] > > > > (eventually, we can merge decoder and ir-core into one module at the > > beginning, > > depending on the size of the decoders) > > > > For device drivers that work only in evdev mode (those with hardware > > decoders): > > > > [IR physical device] ==> [IR receiver driver] ==> [ir-core] ==> [evdev] > > > > Maybe we are talking about the same things and it is just names that are > confusing. I'd imagine something like this: > > > In-kernel decoding: > > [IR physical device] => [IR receiver driver] => [IR core] => [decoder] => > [input core] => [evdev] > => [decoder] => > [input core] => [evdev] > > Hardware decoder: > [IR physical device] => [IR receiver driver] => [IR core] >=> [input core] => [evdev] > > I.e we still register with IR core but driver communicates directly with > input device. > > Userspace decoging: > [IR physical device] => [IR receiver driver] => [IR core] => [lirc_dev] => > [lircd] => [uinput] => [input core] => [evdev] I think, we're thinking the same thing, but I've broke the IR core into two parts: the lirc core, where the LIRC API will be handled, and the IR core, where the input API will be handled. I've
[PATCH] [resend] radio-sf16fmi: add autoprobing
Add automatic probing of ports 0x284 and 0x384 to radio-sf16fmi if no card is
found using PnP.
Signed-off-by: Ondrej Zary
--- linux-source-2.6.31/drivers/media/radio/Kconfig.1 2009-11-28
21:40:32.0 +0100
+++ linux-source-2.6.31/drivers/media/radio/Kconfig 2009-11-28
21:32:58.0 +0100
@@ -199,10 +199,7 @@
tristate "SF16-FMI/SF16-FMP Radio"
depends on ISA && VIDEO_V4L2
---help---
- Choose Y here if you have one of these FM radio cards. If you
- compile the driver into the kernel and your card is not PnP one, you
- have to add "sf16fm=" to the kernel command line (I/O address is
- 0x284 or 0x384).
+ Choose Y here if you have one of these FM radio cards.
In order to control your radio card, you will need to use programs
that are compatible with the Video For Linux API. Information on
--- linux-source-2.6.31/drivers/media/radio/radio-sf16fmi.c.1 2009-11-28
21:27:22.0 +0100
+++ linux-source-2.6.31/drivers/media/radio/radio-sf16fmi.c 2009-11-28
22:15:57.0 +0100
@@ -54,6 +54,7 @@ struct fmi
static struct fmi fmi_card;
static struct pnp_dev *dev;
+bool pnp_attached;
/* freq is in 1/16 kHz to internal number, hw precision is 50 kHz */
/* It is only useful to give freq in interval of 800 (=0.05Mhz),
@@ -316,26 +317,54 @@ static int __init fmi_init(void)
{
struct fmi *fmi = &fmi_card;
struct v4l2_device *v4l2_dev = &fmi->v4l2_dev;
- int res;
+ int res, i;
+ int probe_ports[] = { 0, 0x284, 0x384 };
- if (io < 0)
- io = isapnp_fmi_probe();
- strlcpy(v4l2_dev->name, "sf16fmi", sizeof(v4l2_dev->name));
- fmi->io = io;
- if (fmi->io < 0) {
- v4l2_err(v4l2_dev, "No PnP card found.\n");
- return fmi->io;
+ if (io < 0) {
+ for (i = 0; i < ARRAY_SIZE(probe_ports); i++) {
+ io = probe_ports[i];
+ if (io == 0) {
+ io = isapnp_fmi_probe();
+ if (io < 0)
+ continue;
+ pnp_attached = 1;
+ }
+ if (!request_region(io, 2, "radio-sf16fmi")) {
+ if (pnp_attached)
+ pnp_device_detach(dev);
+ io = -1;
+ continue;
+ }
+ if (pnp_attached ||
+ ((inb(io) & 0xf9) == 0xf9 && (inb(io) & 0x4) == 0))
+ break;
+ release_region(io, 2);
+ io = -1;
+ }
+ } else {
+ if (!request_region(io, 2, "radio-sf16fmi")) {
+ printk(KERN_ERR "radio-sf16fmi: port %#x already in
use\n", io);
+ return -EBUSY;
+ }
+ if (inb(io) == 0xff) {
+ printk(KERN_ERR "radio-sf16fmi: card not present at
%#x\n", io);
+ release_region(io, 2);
+ return -ENODEV;
+ }
}
- if (!request_region(io, 2, "radio-sf16fmi")) {
- v4l2_err(v4l2_dev, "port 0x%x already in use\n", fmi->io);
- pnp_device_detach(dev);
- return -EBUSY;
+ if (io < 0) {
+ printk(KERN_ERR "radio-sf16fmi: no cards found\n");
+ return -ENODEV;
}
+ strlcpy(v4l2_dev->name, "sf16fmi", sizeof(v4l2_dev->name));
+ fmi->io = io;
+
res = v4l2_device_register(NULL, v4l2_dev);
if (res < 0) {
release_region(fmi->io, 2);
- pnp_device_detach(dev);
+ if (pnp_attached)
+ pnp_device_detach(dev);
v4l2_err(v4l2_dev, "Could not register v4l2_device\n");
return res;
}
@@ -352,7 +381,8 @@ static int __init fmi_init(void)
if (video_register_device(&fmi->vdev, VFL_TYPE_RADIO, radio_nr) < 0) {
v4l2_device_unregister(v4l2_dev);
release_region(fmi->io, 2);
- pnp_device_detach(dev);
+ if (pnp_attached)
+ pnp_device_detach(dev);
return -EINVAL;
}
@@ -369,7 +399,7 @@ static void __exit fmi_exit(void)
video_unregister_device(&fmi->vdev);
v4l2_device_unregister(&fmi->v4l2_dev);
release_region(fmi->io, 2);
- if (dev)
+ if (dev && pnp_attached)
pnp_device_detach(dev);
}
--
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [resend] radio-sf16fmi: fix mute, add SF16-FMP to texts
Fix completely broken mute handling radio-sf16fmi.
The sound was muted immediately after tuning in KRadio.
Also fix typos and add SF16-FMP to the texts.
Signed-off-by: Ondrej Zary
diff -urp linux-source-2.6.31-orig/drivers/media/radio/Kconfig
linux-source-2.6.31/drivers/media/radio/Kconfig
--- linux-source-2.6.31-orig/drivers/media/radio/Kconfig2009-09-10
00:13:59.0 +0200
+++ linux-source-2.6.31/drivers/media/radio/Kconfig 2009-11-28
11:51:42.0 +0100
@@ -196,7 +196,7 @@ config RADIO_MAESTRO
module will be called radio-maestro.
config RADIO_SF16FMI
- tristate "SF16FMI Radio"
+ tristate "SF16-FMI/SF16-FMP Radio"
depends on ISA && VIDEO_V4L2
---help---
Choose Y here if you have one of these FM radio cards. If you
diff -urp linux-source-2.6.31-orig/drivers/media/radio/radio-sf16fmi.c
linux-source-2.6.31/drivers/media/radio/radio-sf16fmi.c
--- linux-source-2.6.31-orig/drivers/media/radio/radio-sf16fmi.c
2009-09-10 00:13:59.0 +0200
+++ linux-source-2.6.31/drivers/media/radio/radio-sf16fmi.c 2009-11-28
11:39:35.0 +0100
@@ -1,4 +1,4 @@
-/* SF16FMI radio driver for Linux radio support
+/* SF16-FMI and SF16-FMP radio driver for Linux radio support
* heavily based on rtrack driver...
* (c) 1997 M. Kirkwood
* (c) 1998 Petr Vandrovec, vandr...@vc.cvut.cz
@@ -11,7 +11,7 @@
*
* Frequency control is done digitally -- ie out(port,encodefreq(95.8));
* No volume control - only mute/unmute - you have to use line volume
- * control on SB-part of SF16FMI
+ * control on SB-part of SF16-FMI/SF16-FMP
*
* Converted to V4L2 API by Mauro Carvalho Chehab
*/
@@ -30,14 +30,14 @@
#include
MODULE_AUTHOR("Petr Vandrovec, vandr...@vc.cvut.cz and M. Kirkwood");
-MODULE_DESCRIPTION("A driver for the SF16MI radio.");
+MODULE_DESCRIPTION("A driver for the SF16-FMI and SF16-FMP radio.");
MODULE_LICENSE("GPL");
static int io = -1;
static int radio_nr = -1;
module_param(io, int, 0);
-MODULE_PARM_DESC(io, "I/O address of the SF16MI card (0x284 or 0x384)");
+MODULE_PARM_DESC(io, "I/O address of the SF16-FMI or SF16-FMP card (0x284 or
0x384)");
module_param(radio_nr, int, 0);
#define RADIO_VERSION KERNEL_VERSION(0, 0, 2)
@@ -47,7 +47,7 @@ struct fmi
struct v4l2_device v4l2_dev;
struct video_device vdev;
int io;
- int curvol; /* 1 or 0 */
+ bool mute;
unsigned long curfreq; /* freq in kHz */
struct mutex lock;
};
@@ -105,7 +105,7 @@ static inline int fmi_setfreq(struct fmi
outbits(8, 0xC0, fmi->io);
msleep(143);/* was schedule_timeout(HZ/7) */
mutex_unlock(&fmi->lock);
- if (fmi->curvol)
+ if (!fmi->mute)
fmi_unmute(fmi);
return 0;
}
@@ -116,7 +116,7 @@ static inline int fmi_getsigstr(struct f
int res;
mutex_lock(&fmi->lock);
- val = fmi->curvol ? 0x08 : 0x00;/* unmute/mute */
+ val = fmi->mute ? 0x00 : 0x08; /* mute/unmute */
outb(val, fmi->io);
outb(val | 0x10, fmi->io);
msleep(143);/* was schedule_timeout(HZ/7) */
@@ -204,7 +204,7 @@ static int vidioc_g_ctrl(struct file *fi
switch (ctrl->id) {
case V4L2_CID_AUDIO_MUTE:
- ctrl->value = fmi->curvol;
+ ctrl->value = fmi->mute;
return 0;
}
return -EINVAL;
@@ -221,7 +221,7 @@ static int vidioc_s_ctrl(struct file *fi
fmi_mute(fmi);
else
fmi_unmute(fmi);
- fmi->curvol = ctrl->value;
+ fmi->mute = ctrl->value;
return 0;
}
return -EINVAL;
--
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] V4L - Fix videobuf_dma_contig_user_get() getting page aligned physical address
Hi again Murali, Thanks for your work on this. On Thu, Dec 3, 2009 at 12:48 AM, Karicheri, Muralidharan wrote: > Magnus, > >>Thanks for the patch. For non-page aligned user space pointers I agree >>that a fix is needed. Don't you think the while loop in >>videobuf_dma_contig_user_get() also needs to be adjusted to include >>the last page? I think the while loop checks one page too little in >>the non-aligned case today. > > Thanks for reviewing my patch. It had worked for non-aligned address in > my testing. If I understand this code correctly, the physical address of > the user page start is determined in the first loop (pages_done == 0) > and additional loops are run to make sure the memory is physically > contiguous. Initially the mem->size is set to number of pages aligned to > page size. > > Assume we pass 4097 bytes as size. > > mem->size = PAGE_ALIGN(vb->size); => 2 > > Inside the loop, iteration is done for 0 to pages-1. > > pages_done < (mem->size >> 12) => pages_done < 2 => iterate 2 times > > For size of 4096, we iterate once. > For size of 4095, we iterate once. > > So IMO the loop is already iterate one more time when we pass non-aligned > address since size is aligned to include the last page. So based on this > could you ack my patch so that we could ask Mauro to merge it with priority? I think your observations are correct, but I also think there is one more hidden issue. In the case where the offset within the page is other than 0 then we should loop once more to also check the final page. Right now no one is checking if the last page is contiguous or not in the case on non-page-aligned offset.. So in your case with a 4096 or 4095 size, but if the offset withing the page is non-zero then we should loop twice to make sure the pages really are physically contiguous. Today we only loop once based on the size. We should also include the offset in the calculation of number of pages to check. If you can include that fix in your patch that would be great. If not then i'll fix it up myself. Thanks! / magnus -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Thu, Dec 03, 2009 at 04:33:28PM -0200, Mauro Carvalho Chehab wrote: > Let me draw my view: > > Em Thu, 3 Dec 2009 09:55:31 -0800 > Dmitry Torokhov escreveu: > > > No, please, wait just a minute. I know it is tempting to just merge > > lirc_dev and start working, but can we first agree on the overall > > subsystem structure before doing so. It is still quite inclear to me. > > > > The open questions (for me at least): > > > > - do we create a new class infrastructure for all receivers or only for > > ones plugged into lirc_dev? Remember that classifying objects affects > > how udev and friemds see them and may either help or hurt writing PnP > > rules. > > IMO, I would create it as /sys/class/input/IR (just like the /mice). I That will not work. Driver core does not support notion of subclasses, Greg and Kay insist on flat class namespace. Mice do not belong to a separate [sub]class, they all members of input class, with peculiar directory structure. IRs however, I believe, deserve a full-fledged class (since they are in my view are parents to the input devices representing remotes). I would argus for the following sysfs hierarchy for the main device tree: /sys/devices/pcipci:00/../pci.../../irrcv0/input14/event16 /sys/devices/pcipci:00/../usb.../../irrcv1/input15/event17 /input16/event18 And corresponding class: /sys/class/irrcv/irrcv0 irrcv1 and so on. > > don't see why do we need to different lirc than no-lirc drivers in the > case of sysfs class. I do agree that _all_ infrared receivers should belong to this class, and not only ones utilizing lirc_dev. > As devices with raw input capabilities will have > another dev to communicate, this means that we'll need a /lirc node > there to point to lirc dev. > > > > > - do we intend to support in-kernel sotfware decoders? > > Yes. > Good. > > - What is the structure? Do we organize them as a module to be used by > > driver > > directly or the driver "streams" the data to IR core and the core > > applies decoders (in the same fashion input events from drivers flow > > into input core and then distributed to all bound interfaces for > > processing/conversion/transmission to userspace)? > > My plan is to expand ir-common.ko module and rename it to ir-core, to be > the IR core module for the evdev interface. I'm already working on it. > My idea for an architecture is that the lirc-core module will use > ir-common where the IR decoders will be, and the evdev interface. > How related lirc-core to the current lirc code? If it is not the same maybe we should not call it lirc to avoid confusion. > IMO, we should move them from /drivers/media/common to /drivers/input/ir. > It makes sense to use kfifo to send the data to the in-kernel decoders. > OK. > > - how do we control which decoder should handle particular > > receiver/remote? Is it driver's decision, decoder's decision, user's > > or all of the above? > > It should be all the above, since some hardware will only work with certain > decoders (hardware limitation) or they may have already a raw mode->scancode > legacy decoder. In the latter case, those decoders will be removed from > the existing drivers, but this action will take some time. > > Some sysfs attributes are needed to specify a list of the supported protocols > and the currently used one. I'll prepare a proposed patch for it, after we > finish aligning the requirements. > > > - do we allow to have several decorers active at once for a receiver? > > Yes, as an optional requirement, since some hardware won't support it. > > > - who decides that we want to utilize lirc_dev? Driver's themselves, IR > > core (looking at the driver/device "capabilities"), something else? > > Drivers that support raw mode, should interface via lirc-core, that will, > in turn use ir-core. > > Drivers that have in-hardware decode will directly use ir-core. > > > - do we recognize and create input devices "on-fly" or require user > > intervention? Semantics for splitting into several input/event > > devices? > > I don't have a strong opinion here. > > I don't see any way for doing it, except with very few protocols that > sends vendor IDs. I don't care if this feature can be used by the > drivers/decoders that could support it. > > > Could anyone please draw me a picture, starting with a "receiver" > > piece of hardware. I am not concerned much with how exactly receiver is > > plugged into a particular subsystem (DVB/V4L etc) since it would be > > _their_ implementation detail, but with the flow in/out of that > > "receiver" device. > > Not sure if I got your idea. Basically, what I see is: > > For device drivers that work in raw mode: > [IR physical device] ==> [IR receiver driver] ==> [lirc-core] ==> [decoder] > ==> [ir-core] ==> [evdev] > > (eventually, we can merge decoder and ir-core into one module at the > beginning, > d
[PATCH 1/2 v5] v4l: add a media-bus API for configuring v4l2 subdev pixel and frame formats
Video subdevices, like cameras, decoders, connect to video bridges over
specialised busses. Data is being transferred over these busses in various
formats, which only loosely correspond to fourcc codes, describing how video
data is stored in RAM. This is not a one-to-one correspondence, therefore we
cannot use fourcc codes to configure subdevice output data formats. This patch
adds codes for several such on-the-bus formats and an API, similar to the
familiar .s_fmt(), .g_fmt(), .try_fmt(), .enum_fmt() API for configuring those
codes. After all users of the old API in struct v4l2_subdev_video_ops are
converted, it will be removed. Also add helper routines to support generic
pass-through mode for the soc-camera framework.
Signed-off-by: Guennadi Liakhovetski
Acked-by: Hans Verkuil
---
v4 -> v5: add byte-order annotations to YUV formats.
Other patches in the series adjusted accordingly. This is what I'm going
to push in a few minutes / hours.
drivers/media/video/Makefile |2 +-
drivers/media/video/soc_mediabus.c | 157
include/media/soc_mediabus.h | 65 +++
include/media/v4l2-mediabus.h | 61 ++
include/media/v4l2-subdev.h| 19 -
5 files changed, 302 insertions(+), 2 deletions(-)
create mode 100644 drivers/media/video/soc_mediabus.c
create mode 100644 include/media/soc_mediabus.h
create mode 100644 include/media/v4l2-mediabus.h
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 7a2dcc3..e7bc8da 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -149,7 +149,7 @@ obj-$(CONFIG_VIDEO_VIVI) += vivi.o
obj-$(CONFIG_VIDEO_CX23885) += cx23885/
obj-$(CONFIG_VIDEO_OMAP2) += omap2cam.o
-obj-$(CONFIG_SOC_CAMERA) += soc_camera.o
+obj-$(CONFIG_SOC_CAMERA) += soc_camera.o soc_mediabus.o
obj-$(CONFIG_SOC_CAMERA_PLATFORM) += soc_camera_platform.o
# soc-camera host drivers have to be linked after camera drivers
obj-$(CONFIG_VIDEO_MX1)+= mx1_camera.o
diff --git a/drivers/media/video/soc_mediabus.c
b/drivers/media/video/soc_mediabus.c
new file mode 100644
index 000..c54cae7
--- /dev/null
+++ b/drivers/media/video/soc_mediabus.c
@@ -0,0 +1,157 @@
+/*
+ * soc-camera media bus helper routines
+ *
+ * Copyright (C) 2009, Guennadi Liakhovetski
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+
+#include
+#include
+#include
+
+#define MBUS_IDX(f) (V4L2_MBUS_FMT_ ## f - V4L2_MBUS_FMT_FIXED - 1)
+
+static const struct soc_mbus_pixelfmt mbus_fmt[] = {
+ [MBUS_IDX(YUYV8_2X8_LE)] = {
+ .fourcc = V4L2_PIX_FMT_YUYV,
+ .name = "YUYV",
+ .bits_per_sample= 8,
+ .packing= SOC_MBUS_PACKING_2X8_PADHI,
+ .order = SOC_MBUS_ORDER_LE,
+ }, [MBUS_IDX(YVYU8_2X8_LE)] = {
+ .fourcc = V4L2_PIX_FMT_YVYU,
+ .name = "YVYU",
+ .bits_per_sample= 8,
+ .packing= SOC_MBUS_PACKING_2X8_PADHI,
+ .order = SOC_MBUS_ORDER_LE,
+ }, [MBUS_IDX(YUYV8_2X8_BE)] = {
+ .fourcc = V4L2_PIX_FMT_UYVY,
+ .name = "UYVY",
+ .bits_per_sample= 8,
+ .packing= SOC_MBUS_PACKING_2X8_PADHI,
+ .order = SOC_MBUS_ORDER_LE,
+ }, [MBUS_IDX(YVYU8_2X8_BE)] = {
+ .fourcc = V4L2_PIX_FMT_VYUY,
+ .name = "VYUY",
+ .bits_per_sample= 8,
+ .packing= SOC_MBUS_PACKING_2X8_PADHI,
+ .order = SOC_MBUS_ORDER_LE,
+ }, [MBUS_IDX(RGB555_2X8_PADHI_LE)] = {
+ .fourcc = V4L2_PIX_FMT_RGB555,
+ .name = "RGB555",
+ .bits_per_sample= 8,
+ .packing= SOC_MBUS_PACKING_2X8_PADHI,
+ .order = SOC_MBUS_ORDER_LE,
+ }, [MBUS_IDX(RGB555_2X8_PADHI_BE)] = {
+ .fourcc = V4L2_PIX_FMT_RGB555X,
+ .name = "RGB555X",
+ .bits_per_sample= 8,
+ .packing= SOC_MBUS_PACKING_2X8_PADHI,
+ .order = SOC_MBUS_ORDER_LE,
+ }, [MBUS_IDX(RGB565_2X8_LE)] = {
+ .fourcc = V4L2_PIX_FMT_RGB565,
+ .name = "RGB565",
+ .bits_per_sample= 8,
+ .packing
Re: [PATCH 1/2 v4] v4l: add a media-bus API for configuring v4l2 subdev pixel and frame formats
On Fri, 4 Dec 2009, Hans Verkuil wrote:
> > diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h
> > new file mode 100644
> > index 000..5cf2a6d
> > --- /dev/null
> > +++ b/include/media/v4l2-mediabus.h
> > @@ -0,0 +1,61 @@
> > +/*
> > + * Media Bus API header
> > + *
> > + * Copyright (C) 2009, Guennadi Liakhovetski
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + */
> > +
> > +#ifndef V4L2_MEDIABUS_H
> > +#define V4L2_MEDIABUS_H
> > +
> > +/*
> > + * These pixel codes uniquely identify data formats on the media bus.
> > Mostly
> > + * they correspond to similarly named V4L2_PIX_FMT_* formats, format 0 is
> > + * reserved, V4L2_MBUS_FMT_FIXED shall be used by host-client pairs, where
> > the
> > + * data format is fixed. Additionally, "2X8" means that one pixel is
> > transferred
> > + * in two 8-bit samples, "BE" or "LE" specify in which order those samples
> > are
> > + * transferred over the bus: "LE" means that the least significant bits are
> > + * transferred first, "BE" means that the most significant bits are
> > transferred
> > + * first, and "PADHI" and "PADLO" define which bits - low or high, in the
> > + * incomplete high byte, are filled with padding bits.
> > + */
> > +enum v4l2_mbus_pixelcode {
> > + V4L2_MBUS_FMT_FIXED = 1,
> > + V4L2_MBUS_FMT_YUYV8_2X8,
> > + V4L2_MBUS_FMT_YVYU8_2X8,
> > + V4L2_MBUS_FMT_UYVY8_2X8,
> > + V4L2_MBUS_FMT_VYUY8_2X8,
>
> Darn, I was so hoping that I could sign off on it, but this makes no sense
> now.
>
> Either it is:
>
> V4L2_MBUS_FMT_YUYV8_1X8,
> V4L2_MBUS_FMT_YVYU8_1X8,
> V4L2_MBUS_FMT_UYVY8_1X8,
> V4L2_MBUS_FMT_VYUY8_1X8
>
> where the 'YUYV' code tells you the order of the Y, U and V samples over the
> bus, or it is:
>
> V4L2_MBUS_FMT_YUYV8_2X8_BE,
> V4L2_MBUS_FMT_YUYV8_2X8_LE,
> V4L2_MBUS_FMT_YVYU8_2X8_BE,
> V4L2_MBUS_FMT_YVYU8_2X8_LE,
>
> Where the BE or LE suffix tells you the order in which the YU/YV pairs are
> arriving.
No. In nXk n is the number of k-bit wide _electrical_ samples of the bus
to get (an equivalent of) one _pixel_. So, for 16-bit formats on 8-bit bus
it's _definitely_ 2X8.
And no, BE and LE is the order of _samples_ within one _pixel_, not the
order of pixels within one megapixel ("YU/YV pairs are arriving"), but
that's also what you meant above, judging by the names.
So, I'll go with the 2X8_[LB]E variant, where
YUYV8_2X8_LE == YUYV with LE packing
YUYV8_2X8_BE == UYVY with LE packing
YVYU8_2X8_LE == YVYU with LE packing
YVYU8_2X8_BE == VYUY with LE packing
> Personally I prefer the first (1X8) representation.
> Just pick one of these two and you can send it again and add my signed-off-by:
>
> Signed-off-by: Hans Verkuil
I'll make it an "Acked-by." You can only put an Sob, if you forward a
patch. Otherwise you can only add an Acked-by or a Reviewed-by.
Thanks
Guennadi
>
> Regards,
>
> Hans
>
> > + V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE,
> > + V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE,
> > + V4L2_MBUS_FMT_RGB565_2X8_LE,
> > + V4L2_MBUS_FMT_RGB565_2X8_BE,
> > + V4L2_MBUS_FMT_SBGGR8_1X8,
> > + V4L2_MBUS_FMT_SBGGR10_1X10,
> > + V4L2_MBUS_FMT_GREY8_1X8,
> > + V4L2_MBUS_FMT_Y10_1X10,
> > + V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE,
> > + V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_LE,
> > + V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE,
> > + V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE,
> > +};
> > +
> > +/**
> > + * struct v4l2_mbus_framefmt - frame format on the media bus
> > + * @width: frame width
> > + * @height:frame height
> > + * @code: data format code
> > + * @field: used interlacing type
> > + * @colorspace:colorspace of the data
> > + */
> > +struct v4l2_mbus_framefmt {
> > + __u32 width;
> > + __u32 height;
> > + enum v4l2_mbus_pixelcodecode;
> > + enum v4l2_field field;
> > + enum v4l2_colorspacecolorspace;
> > +};
> > +
> > +#endif
> > diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
> > index 544ce87..c53d462 100644
> > --- a/include/media/v4l2-subdev.h
> > +++ b/include/media/v4l2-subdev.h
> > @@ -22,6 +22,7 @@
> > #define _V4L2_SUBDEV_H
> >
> > #include
> > +#include
> >
> > /* generic v4l2_device notify callback notification values */
> > #define V4L2_SUBDEV_IR_RX_NOTIFY _IOW('v', 0, u32)
> > @@ -207,7 +208,7 @@ struct v4l2_subdev_audio_ops {
> > s_std_output: set v4l2_std_id for video OUTPUT devices. This is ignored
> > by
> > video input devices.
> >
> > - s_crystal_freq: sets the frequency of the crystal used to generate the
> > + s_crystal_freq: sets the frequency of the crystal used to generate the
> > clocks in Hz. An extra flags field allows device specific configuration
> > regarding clo
Re: V4L1 compatibility broken for VIDIOCGTUNER with radio
On Thu, Dec 3, 2009 at 8:10 PM, hermann pitton wrote:
>
> Am Donnerstag, den 03.12.2009, 21:04 -0200 schrieb Herton Ronaldo
> Krzesinski:
>> Em Qui 03 Dez 2009, às 19:54:29, hermann pitton escreveu:
>> > Hi,
>> >
>> > Am Donnerstag, den 03.12.2009, 16:56 -0200 schrieb Herton Ronaldo
>> > Krzesinski:
>> > > Hi,
>> > >
>> > > After commit 9bedc7f ("V4L/DVB (12429): v4l2-ioctl: fix G_STD and G_PARM
>> > > default handlers"), radio software using V4L1 stopped to work on a
>> > > saa7134
>> > > card, a git bisect pointed to this commit introducing the regression. All
>> > > VIDIOCGTUNER calls on a v4l1 application are returning -EINVAL after this
>> > > commit.
>> > >
>> > > Investigating the issue, it turns out that v4l1_compat_get_tuner calls
>> > > VIDIOC_G_STD ioctl, but as it is a radio device (saa7134-radio) it now is
>> > > returning -EINVAL to user space applications which are being confused
>> > > about
>> > > this.
>> > >
>> > > May be VIDIOC_G_STD change in the commit above should be reverted, or
>> > > v4l1_compat_get_tuner changed to not return error with G_STD, or not call
>> > > G_STD ioctl for a radio device?
>> > >
>> > > --
>> > > []'s
>> > > Herton
>> >
>> > it was fixed here.
>> >
>> > http://linuxtv.org/hg/v4l-dvb/rev/58ecda742a70
>>
>> Indeed, thanks for the pointer. I forgot to check latest v4l1-compat.c /o\
>>
>> >
>> > Maybe it was not ported to stable?
>>
>> Not on latest stable (2.6.31.6), perhaps it should be forwarded.
>>
>
> Yes, for sure. It's our fault.
>
> Seems we had an "internal server error" :(
>
> I came across it by accident.
>
>> The only other issue I'm aware of is that radio is broken since guessed
>> 8 weeks on my tuners, only realized when testing on enabling external
>> active antenna voltage for DVB-T on a/some 310i.
>
> I did the bisect with some delay and Hans marked the fix with priority
> "high", but we missed to point Mike at it for stable explicitly.
>
> Mike, please review and forward.
>
> Sorry,
> Hermann
Already done. It's queued for 2.6.31.7 The delay was due to the
standard bureaucracy ... nothing we haven't seen before -- hopefully
the distros will take in in once it's merged to stable, which should
probably be within the next week or two.
Thanks,
Mike
--
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
