Re: [RFC/PATCH 2/3] v4l: Document integer menu controls
Hi Sylwester, On Fri, Nov 25, 2011 at 12:17:58AM +0100, Sylwester Nawrocki wrote: ... > > @@ -292,6 +313,20 @@ the menu items can be enumerated with the > > VIDIOC_QUERYMENU ioctl. > > > > > > + V4L2_CTRL_TYPE_INTEGER_MENU > > + ≥ 0 > > + 1 > > + N-1 > > + > > + The control has a menu of N choices. The names of the > > + menu items can be enumerated with the > > Shouldn't it be something along the lines of "The integer values of > the menu items can be enumerated..." ? Right. This is left from the original menu control definition I copied. I'll fix this in the next version of the patchset. Cheers, -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- 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 08/13: 0008-STV090x-Query-DVB-frontend-delivery-capabilities
Acked-by: Oliver Endriss CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- 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 v3: Query DVB frontend delivery capabilities (was: Re: PATCH: Query DVB frontend capabilities)
On Monday 14 November 2011 20:39:48 Manu Abraham wrote: > On 11/12/11, Andreas Oberritter wrote: > > On 11.11.2011 23:38, Mauro Carvalho Chehab wrote: > >> Em 11-11-2011 20:07, Manu Abraham escreveu: > >>> On Fri, Nov 11, 2011 at 3:42 PM, Mauro Carvalho Chehab > >>> wrote: > Em 11-11-2011 04:26, Manu Abraham escreveu: > > On Fri, Nov 11, 2011 at 2:50 AM, Mauro Carvalho Chehab > > wrote: > >> Em 10-11-2011 13:30, Manu Abraham escreveu: > > The purpose of the patch is to > > query DVB delivery system capabilities alone, rather than DVB frontend > > info/capability. > > > > Attached is a revised version 2 of the patch, which addresses the > > issues that were raised. > > It looks good for me. I would just rename it to DTV_SUPPORTED_DELIVERY. > Please, when submitting upstream, don't forget to increment DVB version > and > add touch at DocBook, in order to not increase the gap between API specs > and the > implementation. > >>> > >>> Ok, thanks for the feedback, will do that. > >>> > >>> The naming issue is trivial. I would like to have a shorter name > >>> rather that SUPPORTED. CAPS would have been ideal, since it refers to > >>> device capability. > >> > >> CAPS is not a good name, as there are those two CAPABILITIES calls there > >> (well, currently not implemented). So, it can lead in to some confusion. > >> > >> DTV_ENUM_DELIVERY could be an alternative for a short name to be used > >> there. > > > > I like "enum", because it suggests that it's a read-only property. > > > > DVB calls them "delivery systems", so maybe DTV_ENUM_DELSYS may be an > > alternative. > > This is a bit more sensible and meaningful than the others. I like > this one better than the others. > > Attached is a version 3 patch which addresses all the issues that were raised. Fine for me. (I do not care about the name of the game.) Acked-by: Oliver Endriss CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- 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: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.
Em 24-11-2011 23:09, Andreas Oberritter escreveu: > On 24.11.2011 19:25, Mauro Carvalho Chehab wrote: >> Em 24-11-2011 16:07, Andreas Oberritter escreveu: >>> On 24.11.2011 18:58, Mauro Carvalho Chehab wrote: Em 24-11-2011 15:51, Andreas Oberritter escreveu: > On 24.11.2011 18:44, Hans Verkuil wrote: >> On Thursday, November 24, 2011 18:08:05 Andreas Oberritter wrote: >>> Don't break existing Userspace APIs for no reason! It's OK to add the >>> new API, but - pretty please - don't just blindly remove audio.h and >>> video.h. They are in use since many years by av7110, out-of-tree drivers >>> *and more importantly* by applications. Yes, I know, you'd like to see >>> those out-of-tree drivers merged, but it isn't possible for many >>> reasons. And even if they were merged, you'd say "Port them and your >>> apps to V4L". No! That's not an option. >> >> I'm not breaking anything. All apps will still work. >> >> One option (and it depends on whether people like it or not) is to have >> audio.h, video.h and osd.h just include av7110.h and add a #warning >> that these headers need to be replaced by the new av7110.h. >> >> And really remove them at some point in the future. >> >> But the important thing to realize is that the ABI hasn't changed (unless >> I made a mistake somewhere). > > So why don't you just leave the headers where they are and add a notice > about the new V4L API as a comment? > > What you proposed breaks compilation. If you add a warning, it breaks > compilation for programs compiled with -Werror. Both are regressions. I don't mind doing it for 3.3 kernel, and add a note at Documentation/feature-removal-schedule.txt that the headers will go away on 3.4. This should give distributions and app developers enough time to prevent build failures, and prepare for the upcoming changes. >>> >>> Are you serious? >>> >>> Breaking things that worked well for many years - for an artificially >>> invented reason - is so annoying, I can't even find the words to express >>> how much this sucks. >> >> Andreas, >> >> All the in-kernel API's are there to support in-kernel drivers. >> >> Out of tree drivers can do whatever they want. As you likely know, several >> STB >> vendors have their own API's. >> >> Some use some variants of DVBv3 or DVBv5, and some use their own proprietary >> API's, that are even incompatible with DVB (and some even provide both). >> >> Even the ones that use DVBv3 (or v5) have their own implementation that >> diverges >> from the upstream one. >> >> Provided that such vendors don't violate the Kernel GPLv2 license where it >> applies, >> they're free do do whatever they want, forking the DVB API, or creating >> their own >> stacks. > > You're encouraging people to do their own stuff instead of using and > contributing to a common API? Not at all, but this is what happens when drivers are out-of-tree. The only way to avoid it to happen is to merge the drivers upstream. > Anyway, you're talking about the DVB API as a whole, which of course > diverges a little bit from upstream in every implementation, because > patches to enhance the API are generally rejected if no in-kernel driver > uses the new function/flag/whatever at the time of its introduction. I > would have submitted many more API enhancements in the past, if you > wouldn't force that strict policy. Instead I usually have to wait until > another developer does the same job and then merge our work. There are no restrictions for you to merge your API enhancements with your drivers. > On the other hand, S2API was merged upstream with many unused "DTV_xxx" > commands and unused structs in the public header, being incomplete at > the same time (e.g. missing DiSEqC support and signal quality > measurements functions). Yes, this was a big mistake. It should never happen again. On that time, I trusted that the developer that proposed S2API would provide us both API documentation and the missing features, as promised, with unfortunately didn't happen. This is one more reason for me to not accept anymore patches that adds incomplete stuff at the Kernel API's: a new API patch series now needs to provide: - API bits; - Documentation; - driver using it. This is the only way to be sure that everything is all set, and to warrant that other drivers using the API will behave like the first one that added it. >> So, keeping the in-kernel unused ioctl's don't bring any real benefit, as >> vendors >> can still do their forks, and applications designed to work with those >> hardware >> need to support the vendor's stack. > > Can you please list all unused ioctls? As you know, av7110 uses some of > them and Manu is currently developing another open source driver using > the audio and video APIs. Please don't pretend that all ioctls are > unused to justify a removal of the whole API.
Re: PATCH 12/13: 0012-CXD2820r-Query-DVB-frontend-delivery-capabilities
Em 21-11-2011 21:01, Manu Abraham escreveu:
> Hi,
>
> On Tue, Nov 22, 2011 at 3:58 AM, Antti Palosaari wrote:
>> Hello
>>
>> On 11/21/2011 11:09 PM, Manu Abraham wrote:
>>>
>>>/* program tuner */
>>> - if (fe->ops.tuner_ops.set_params)
>>> - fe->ops.tuner_ops.set_params(fe, params);
>>> + tstate.delsys = SYS_DVBC_ANNEX_AC;
>>> + tstate.frequency = c->frequency;
>>> +
>>> + if (fe->ops.tuner_ops.set_state) {
>>> + fe->ops.tuner_ops.set_state(fe,
>>> + DVBFE_TUNER_DELSYS|
>>> + DVBFE_TUNER_FREQUENCY,
>>> + &tstate);
>>
>> I want to raise that point, switch from .set_params() to .set_state() when
>> programming tuner. I don't see it reasonable to introduce (yes, it have
>> existed ages but not used) new way to program tuner.
>
>
> I didn't introduce set_state() now. It was there for quite a long
> while, as old v5API itself, IIRC.
>
>
>>
>> Both demod and tuner got same params;
>> .set_frontend(struct dvb_frontend *, struct dvb_frontend_parameters *)
>> .set_params(struct dvb_frontend *, struct dvb_frontend_parameters *)
>
>
> The argument passed to set_params: struct dvb_frontend_parameters is
> useless for any device that's been around recently. Although one can
> get the parameters from the property_cache.
I like the idea of getting rid of struct dvb_frontend_parameters.
>
> Using set_state(), makes it independant and less kludgy, simplifying
> things. on the other hand it may be used with analog as well, llly to
> Michael Krufky said.
>
> Eventually, it just provides the tuner an independence from struct
> dvb_frontend_parameters (which is rigid) and the frontend cache.
>
> That said, a few tuners already uses the mentioned callback, stb6100,
> tda8261, tda665x,
Hmm... while enum tuner_param is defined as a bitmask, stb6100 implements
it as:
static int stb6100_set_state(struct dvb_frontend *fe,
enum tuner_param param,
struct tuner_state *state)
{
struct stb6100_state *tstate = fe->tuner_priv;
switch (param) {
case DVBFE_TUNER_FREQUENCY:
stb6100_set_frequency(fe, state->frequency);
tstate->frequency = state->frequency;
break;
case DVBFE_TUNER_TUNERSTEP:
And get_state current implementations return only one value each time.
I agree with Antti: the way it is designed doesn't seem to help much,
for a few reasons:
1) at get, one call is needed for each parameter, on the current drivers.
Not a big issue, as patches fixing it may be added anytime.
2) The enum tuner_param field is limited to 32 bits. Currently, DTV_MAX_COMMAND
is equal to 44. Ok, a tuner in general only need a small subset of the
parameters, but 32 bits may starve too fast, depending on how complex
will be the tuner staging for upcoming standards.
3) making tuner DVB or V4L agnostic would mean that the data would need
to be copied from/to the tuner_state struct. The current struct has 6
parameters. Patch 3/13 added 2 more parameters. If we pass the bandwidth
calculus for DVB-S/S2/C/C2 to the frontend, rollback and symbol_rate would
also needed to be there. Other data that is inside dvb_frontend would also
require to be copied. For Analog standards, the analog parameters would
also need to be there (like, for example, the analog standard).
I'm in favor of not trying to merge analog and dvb parameter setting.
I can see two approaches:
1) a simpler interface, like:
static int set_foo(struct dvb_frontend *fe);
and
static int get_foo(struct dvb_frontend *fe);
2) a real cache-based struct:
Add some bitmap fields at struct dtv_frontend_properties in order to
indicate what parameters are new, on a set operations, and what
parameters are dirty (e. g. were modified by the tuner) on return.
This way, a call like:
err = tuner_ops->set_state(fe, DVBFE_TUNER_FREQUENCY, &state);
could still be done using the new interface, allowing drivers to just
set the frequency and preserving the rest.
This would also reduce the amount of time needed to flush data from/to
the cache inside the core (if needed).
I suspect, however, that the code inside the core will reduce a lot if we
get rid of struct dvb_frontend_parameters inside the demods/tuners.
So, IMHO, approach (1) is better.
> If you imply that you feel overly depressed by the use of the
> set_state in the cxd2820r module ;-), then as a workaround, the
> parameters required for operation can be retrieved from the property
> cache, but then if tuner drivers are cleaned up by someone to remove
> obsolete ? set_params, then you wouldn't have any other option, but to
> later on fall back to set_state.
>
> I am fine with either way, but for the tuners themselves, set_state
> behaves a bit more better as it provides independence from
Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.
On 24.11.2011 19:25, Mauro Carvalho Chehab wrote:
> Em 24-11-2011 16:07, Andreas Oberritter escreveu:
>> On 24.11.2011 18:58, Mauro Carvalho Chehab wrote:
>>> Em 24-11-2011 15:51, Andreas Oberritter escreveu:
On 24.11.2011 18:44, Hans Verkuil wrote:
> On Thursday, November 24, 2011 18:08:05 Andreas Oberritter wrote:
>> Don't break existing Userspace APIs for no reason! It's OK to add the
>> new API, but - pretty please - don't just blindly remove audio.h and
>> video.h. They are in use since many years by av7110, out-of-tree drivers
>> *and more importantly* by applications. Yes, I know, you'd like to see
>> those out-of-tree drivers merged, but it isn't possible for many
>> reasons. And even if they were merged, you'd say "Port them and your
>> apps to V4L". No! That's not an option.
>
> I'm not breaking anything. All apps will still work.
>
> One option (and it depends on whether people like it or not) is to have
> audio.h, video.h and osd.h just include av7110.h and add a #warning
> that these headers need to be replaced by the new av7110.h.
>
> And really remove them at some point in the future.
>
> But the important thing to realize is that the ABI hasn't changed (unless
> I made a mistake somewhere).
So why don't you just leave the headers where they are and add a notice
about the new V4L API as a comment?
What you proposed breaks compilation. If you add a warning, it breaks
compilation for programs compiled with -Werror. Both are regressions.
>>>
>>> I don't mind doing it for 3.3 kernel, and add a note at
>>> Documentation/feature-removal-schedule.txt that the
>>> headers will go away on 3.4. This should give distributions
>>> and app developers enough time to prevent build failures, and
>>> prepare for the upcoming changes.
>>
>> Are you serious?
>>
>> Breaking things that worked well for many years - for an artificially
>> invented reason - is so annoying, I can't even find the words to express
>> how much this sucks.
>
> Andreas,
>
> All the in-kernel API's are there to support in-kernel drivers.
>
> Out of tree drivers can do whatever they want. As you likely know, several
> STB
> vendors have their own API's.
>
> Some use some variants of DVBv3 or DVBv5, and some use their own proprietary
> API's, that are even incompatible with DVB (and some even provide both).
>
> Even the ones that use DVBv3 (or v5) have their own implementation that
> diverges
> from the upstream one.
>
> Provided that such vendors don't violate the Kernel GPLv2 license where it
> applies,
> they're free do do whatever they want, forking the DVB API, or creating their
> own
> stacks.
You're encouraging people to do their own stuff instead of using and
contributing to a common API?
Anyway, you're talking about the DVB API as a whole, which of course
diverges a little bit from upstream in every implementation, because
patches to enhance the API are generally rejected if no in-kernel driver
uses the new function/flag/whatever at the time of its introduction. I
would have submitted many more API enhancements in the past, if you
wouldn't force that strict policy. Instead I usually have to wait until
another developer does the same job and then merge our work.
On the other hand, S2API was merged upstream with many unused "DTV_xxx"
commands and unused structs in the public header, being incomplete at
the same time (e.g. missing DiSEqC support and signal quality
measurements functions).
> So, keeping the in-kernel unused ioctl's don't bring any real benefit, as
> vendors
> can still do their forks, and applications designed to work with those
> hardware
> need to support the vendor's stack.
Can you please list all unused ioctls? As you know, av7110 uses some of
them and Manu is currently developing another open source driver using
the audio and video APIs. Please don't pretend that all ioctls are
unused to justify a removal of the whole API.
> On the other hand, keeping an outdated API that doesn't fit well for the
> vendors
> that want to upstream their STB drivers is bad, as it creates confusion for
> them, and prevents innovation, as they may try to workaround on the
> limitation of
> an API designed for the first generation DVB standards.
Can you elaborate which parts of the current generation DVB standards
limit the use of the audio and video API, apart from the missing video
codec flags, which were sent to the mailing list as a patch in 2006?
As already said in another mail today, a comment explaining the
existence and benefits of the V4L video decoder API at the top of
linux/dvb/{audio,video}.h would stop the confusion you're talking about.
Btw.: How does V4l replace osd.h and audio.h? I know that osd.h has been
deprecated for many years, but all reasoning I've heard in this thread
until now was that V4L was superior to the DVB video decoder API.
> That's what Hans patches are addressing.
Re: BUG: scheduling while atomic: kworker/0:0/0/0x00000100
On Thu, 2011-11-24 at 19:02 +, Stefan Macher wrote: > > Hi, > > I have setup a new vdr with yavdr 0.4 with one TT full-featured DVB-S > card (S2300) and one Mystique SaTiX-S2 Sky Xpress dual. As soon as I > pause the video I get endless reports like the one in the headline and > the vdr is dead. > > Because of the new SaTiX card I had to update the DVB drivers to the > latest media-tree. I tried the yavdr kernel 2.6.38-12, a vanilla 3.0.9 > kernel and I also tested the DVB driver from dvbsky.net on top of > vanilla 3.0.9. I always get the same result - working perfectly until > I press pause. > > In the log below schedule is called by play_video_cb (dvb-ttpci). Any > help is appreciated. It appears the ttpci driver has an architectural problem. There are two obvious courses of action to fix the driver: 1. Rework the driver so that it uses workqueues instead of tasklets (tasklets are deprecated). Code executed by a workqueue worker thread is permitted to sleep. Code executed in a tasklet context is not permitted to sleep. or 2. Rework the driver to avoid all mutex locks, or other schedule()-ing calls, in all code paths possibly called in a tasklet context. Both options require a non-trivial amount of work and regression testing, but I estimate option #1 requires less effort. You have a 3rd option option: 3. Don't press "pause" Regards, Andy > /Stefan > > LOG: > > Nov 22 20:19:23 vdr4 kernel: [ 1881.295798] BUG: scheduling while atomic: > kworker/0:0/0/0x0100 > Nov 22 20:19:23 vdr4 kernel: [ 1881.295806] Modules linked in: > snd_hda_codec_hdmi snd_hda_codec_realtek speedstep_lib nfsd exportfs nfs > lockd fscache auth_rpcgss nfs_acl rc_dvbsky ds3000 lnbp21 sunrpc stv0299 > cx25840 ir_lirc_codec lirc_dev snd_hda_intel snd_hda_codec ir_mce_kbd_decoder > snd_hwdep ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder > ir_nec_decoder cx23885 rc_core snd_pcm snd_seq_midi snd_rawmidi > snd_seq_midi_event cx2341x videobuf_dvb v4l2_common snd_seq dvb_ttpci > dvb_core saa7146_vv snd_timer snd_seq_device snd mxm_wmi saa7146 videodev > soundcore videobuf_dma_sg videobuf_core v4l2_compat_ioctl32 ttpci_eeprom > psmouse snd_page_alloc serio_raw video btcx_risc tveeprom edac_core > edac_mce_amd k8temp shpchp i2c_nforce2 lp parport floppy firewire_ohci > firewire_core crc_itu_t forcedeth ahci libahci > Nov 22 20:19:23 vdr4 kernel: [ 1881.295863] CPU 1 > Nov 22 20:19:23 vdr4 kernel: [ 1881.295864] Modules linked in: > snd_hda_codec_hdmi snd_hda_codec_realtek speedstep_lib nfsd exportfs nfs > lockd fscache auth_rpcgss nfs_acl rc_dvbsky ds3000 lnbp21 sunrpc stv0299 > cx25840 ir_lirc_codec lirc_dev snd_hda_intel snd_hda_codec ir_mce_kbd_decoder > snd_hwdep ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder > ir_nec_decoder cx23885 rc_core snd_pcm snd_seq_midi snd_rawmidi > snd_seq_midi_event cx2341x videobuf_dvb v4l2_common snd_seq dvb_ttpci > dvb_core saa7146_vv snd_timer snd_seq_device snd mxm_wmi saa7146 videodev > soundcore videobuf_dma_sg videobuf_core v4l2_compat_ioctl32 ttpci_eeprom > psmouse snd_page_alloc serio_raw video btcx_risc tveeprom edac_core > edac_mce_amd k8temp shpchp i2c_nforce2 lp parport floppy firewire_ohci > firewire_core crc_itu_t forcedeth ahci libahci > Nov 22 20:19:23 vdr4 kernel: [ 1881.295910] > Nov 22 20:19:23 vdr4 kernel: [ 1881.295913] Pid: 0, comm: kworker/0:0 Not > tainted 3.1.0-media+ #1 System manufacturer System Product Name/M3N78-EM > Nov 22 20:19:23 vdr4 kernel: [ 1881.295919] RIP: 0010:[] > [] native_safe_halt+0xb/0x10 > Nov 22 20:19:23 vdr4 kernel: [ 1881.295928] RSP: 0018:88007432fe88 > EFLAGS: 0246 > Nov 22 20:19:23 vdr4 kernel: [ 1881.295931] RAX: RBX: > 8101aa95 RCX: > Nov 22 20:19:23 vdr4 kernel: [ 1881.295934] RDX: RSI: > 88007432fec4 RDI: > Nov 22 20:19:23 vdr4 kernel: [ 1881.295936] RBP: 88007432fe88 R08: > R09: > Nov 22 20:19:23 vdr4 kernel: [ 1881.295939] R10: R11: > R12: 880077c91200 > Nov 22 20:19:23 vdr4 kernel: [ 1881.295941] R13: 00ff8800 R14: > R15: 880071760058 > Nov 22 20:19:23 vdr4 kernel: [ 1881.295945] FS: 7fe326c31740() > GS:880077c8() knlGS: > Nov 22 20:19:23 vdr4 kernel: [ 1881.295948] CS: 0010 DS: ES: CR0: > 8005003b > Nov 22 20:19:23 vdr4 kernel: [ 1881.295951] CR2: 7fe2fc5efac4 CR3: > 71d26000 CR4: 06e0 > Nov 22 20:19:23 vdr4 kernel: [ 1881.295953] DR0: DR1: > DR2: > Nov 22 20:19:23 vdr4 kernel: [ 1881.295956] DR3: DR6: > 0ff0 DR7: 0400 > Nov 22 20:19:23 vdr4 kernel: [ 1881.295959] Process kworker/0:0 (pid: 0, > threadinfo 88007432e000, task 88007433) > Nov 22 20:19:23 vdr4 kernel: [ 1881.295962] Stack: >
Re: [PATCH] Fix tm6010 audio
Hi
> Em 07-11-2011 22:45, Dmitri Belimov escreveu:
> > Hi
> >
> > I found why audio dosn't work for me and fix it.
> >
> > 2Stefan:
> > The V4L2_STD_DK has V4L2_STD_SECAM_DK but not equal
> > switch-case statement not worked
> >
> > you can use
> > if (dev->norm & V4L2_STD_DK) {
> > }
> >
> > This patch fix this problem.
> >
> > Other, please don't remove any workarounds without important reason.
> > For your chip revision it can be work but for other audio will be
> > bad.
> >
> > I can watch TV but radio not work. After start Gnomeradio I see
> > VIDIOCGAUDIO incorrect
> > VIDIOCSAUDIO incorrect
> > VIDIOCSFREQ incorrect
> >
> > Try found what happens with radio.
>
> This patch has several issues. The usage of switch for video doesn't
> work well. A better approach follows. Not tested yet.
>
> PS.: I couldn't test it: not sure why, but the audio source is not
> working for me: arecord is not able to read from the device input.
URB_MSG_AUDIO is zero size no data for fill to audio buffer.
for watch TV I used this command
mplayer -v tv:// -tv
driver=v4l2:fps=25:outfmt=i420:width=720:height=576:alsa:adevice=hw.1,0:amode=1:audiorate=48000:forceaudio:immediatemode=0:freq=77.25:normid=15
-aspect 4:3 -vo xv
AFTER this command radio can works
URB_MSG_AUDIO is not zero and audio buffer filled.
I think incorrect init a register. When I start mplayer a register set correct
mode and audio
via arecord and sox can work.
I try found it.
With my best regards, Dmitry.
> -
> [media] tm6000: Fix tm6010 audio standard selection
>
> A V4L2 standards mask may contain several standards. A more restricted
> mask with just one standard is used when user needs to bind to an
> specific standard that can't be auto-detect among a more generic mask.
>
> So, Improve the autodetection logic to detect the correct audio
> standard most of the time.
>
> Based on a patch made by Dmitri Belimov .
>
> Signed-off-by: Mauro Carvalho Chehab
>
>
> diff --git a/drivers/media/video/tm6000/tm6000-core.c
> b/drivers/media/video/tm6000/tm6000-core.c index 9783616..55d097e
> 100644 --- a/drivers/media/video/tm6000/tm6000-core.c
> +++ b/drivers/media/video/tm6000/tm6000-core.c
> @@ -696,11 +696,13 @@ int tm6000_set_audio_rinput(struct tm6000_core
> *dev) if (dev->dev_type == TM6010) {
> /* Audio crossbar setting, default SIF1 */
> u8 areg_f0;
> + 0x30, 0xf0);
> break;
> default:
> break;
--
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 00/13: Enumerate DVB frontend Delivery System capabilities to identify devices correctly.
Em 21-11-2011 22:43, Manu Abraham escreveu: > On Tue, Nov 22, 2011 at 5:52 AM, Andreas Oberritter wrote: >> On 21.11.2011 22:05, Manu Abraham wrote: >>> Hi, >>> >>> As discussed prior, the following changes help to advertise a >>> frontend's delivery system capabilities. >>> >>> Sending out the patches as they are being worked out. >>> >>> The following patch series are applied against media_tree.git >>> after the following commit >> >> Patches 7, 9 and 10 semm to be unneeded, because they just set the defaults. >> > > cx24116 AFAIR handles dss, but no code exists in the driver to handle the > same. > ds3000, I have no clue > tda10071, is a derivative of the CX demods and likely supports DSS, > just like the ST ones. cx24123 also handles dss, but the driver doesn't support it, AFAICT. > but that said no code exists in the driver. > > As you state, yes, it is pointless to have these 3 patches, Yes, with the current way. > but then I > thought maybe if someone adds in DSS it would be okay. DSS hasn't been > added to most frontends for the reasons > > - earlier there was no support from the frontend API > - need to handle it with demux as well. > > Well, anyway patch exists, so anyone can add it in later if they need > when adding support to the driver. > >> Regarding the patches adding SYS_DSS: If I remember correctly, DSS >> doesn't use MPEG-2 TS packets. Do we have a way to deliver DSS payload >> to userspace? > > Yes, even the SYNC is different, length is different too. Somebody > wrote a parser a while back. But nothing happened on that front due to > the mentioned 2 reasons. > > there are 2 options, > > - send the captured packets as it is to userspace > - based on delivery system (dvb-s2 has generic streams as well, other > than MPEG2-TS, didn't look at dvb-t2, most likely the same option > exists there as well), look for sync and length, send packets to > userspace. Just flagging that the driver supports DSS won't work, as there's currently no way for userspace to get it. My suggestion is to delay those patches to be added after we have a solution that works for DSS, or if we end by getting rid of the compat code inside the drivers (e. g. use struct dvb_frontend_parameters only at the part of the DVB core that provides backward support for v3 calls). > > 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 Regards, 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 04/13: 0004-TDA18271-Allow-frontend-to-set-DELSYS
Em 21-11-2011 22:04, Andreas Oberritter escreveu:
> On 21.11.2011 22:06, Manu Abraham wrote:
>>
>> 0004-TDA18271-Allow-frontend-to-set-DELSYS-rather-than-qu.patch
>>
>>
>> From 2ece38602678ae323450d0e35379147e6e086326 Mon Sep 17 00:00:00 2001
>> From: Manu Abraham
>> Date: Sat, 19 Nov 2011 19:50:09 +0530
>> Subject: [PATCH 04/13] TDA18271: Allow frontend to set DELSYS, rather than
>> querying fe->ops.info.type
>>
>> With any tuner that can tune to multiple delivery systems/standards, it does
>> query fe->ops.info.type to determine frontend type and set the delivery
>> system type. fe->ops.info.type can handle only 4 delivery systems, viz
>> FE_QPSK,
>> FE_QAM, FE_OFDM and FE_ATSC.
>>
>> The change allows the tuner to be set to any delivery system specified in
>> fe_delivery_system_t, thereby simplifying a lot of issues.
>>
>> Signed-off-by: Manu Abraham
>> ---
>> drivers/media/common/tuners/tda18271-fe.c | 80
>> +++
>> drivers/media/common/tuners/tda18271-priv.h |2 +
>> 2 files changed, 82 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/media/common/tuners/tda18271-fe.c
>> b/drivers/media/common/tuners/tda18271-fe.c
>> index 3347c5b..6e29faf 100644
>> --- a/drivers/media/common/tuners/tda18271-fe.c
>> +++ b/drivers/media/common/tuners/tda18271-fe.c
>> @@ -928,6 +928,85 @@ fail:
>>
>> /* -- */
>>
>> +static int tda18271_set_state(struct dvb_frontend *fe,
>> + enum tuner_param param,
>> + struct tuner_state *state)
>> +{
>> +struct tda18271_priv *priv = fe->tuner_priv;
>> +struct tuner_state *req = &priv->request;
>> +struct tda18271_std_map *std_map = &priv->std;
>> +struct tda18271_std_map_item *map;
>> +int ret;
>> +
>> +BUG_ON(!priv);
>
> At this point priv has already been dereferenced.
>
>> +if (param & DVBFE_TUNER_DELSYS)
>> +req->delsys = state->delsys;
>> +if (param & DVBFE_TUNER_FREQUENCY)
>> +req->frequency = state->frequency;
>> +if (param & DVBFE_TUNER_BANDWIDTH)
>> +req->bandwidth = state->bandwidth;
>
> What happens if one of these flags is not set, when the function is
> called for the first time? priv->request doesn't seem to get initialized.
>
> Regards,
> Andreas
>
>> +
>> +priv->mode = TDA18271_DIGITAL;
>> +
>> +switch (req->delsys) {
>> +case SYS_ATSC:
>> +map = &std_map->atsc_6;
>> +req->bandwidth = 600;
>> +break;
>> +case SYS_DVBC_ANNEX_B:
>> +map = &std_map->qam_6;
>> +req->bandwidth = 600;
>> +break;
>> +case SYS_DVBT:
>> +case SYS_DVBT2:
>> +switch (req->bandwidth) {
>> +case 600:
>> +map = &std_map->dvbt_6;
>> +break;
>> +case 700:
>> +map = &std_map->dvbt_7;
>> +break;
>> +case 800:
>> +map = &std_map->dvbt_8;
>> +break;
>> +default:
>> +ret = -EINVAL;
>> +goto fail;
>> +}
>> +break;
>> +case SYS_DVBC_ANNEX_AC:
>> +map = &std_map->qam_8;
>> +req->bandwidth = 800;
>> +break;
This premise is not correct, and causes tuning failure on places where
channels are spaced with 6MHz.
The bandwidth should be calculated as a function of the rolloff and symbol
rate. I had to fix it on a few places, for devices to work with Net Digital
Cable operator in Brazil (6MHz spaced channels, 5.217 KBauds per carrier,
DVB-C Annex A).
The correct way for doing it is:
else if (fe->ops.info.type == FE_QAM) {
/*
* Using a higher bandwidth at the tuner filter may
* allow inter-carrier interference.
* So, determine the minimal channel spacing, in order
* to better adjust the tuner filter.
* According with ITU-T J.83, the bandwidth is given by:
* bw = Simbol Rate * (1 + roll_off), where the roll_off
* is equal to 0.15 for Annex A, and 0.13 for annex C
*/
if (fe->dtv_property_cache.rolloff == ROLLOFF_13)
bw = (params->u.qam.symbol_rate * 13) / 10;
else
bw = (params->u.qam.symbol_rate * 15) / 10;
if (bw <= 600)
Standard = HF_DVBC_6MHZ;
else if (bw <= 700)
Standard = HF_DVBC_7MHZ;
else
Standard = HF_DVBC_8MHZ;
(from drivers/media/dvb/frontends/tda18271c2dd.c)
Where ROLLOFF_13 is used on Annex C, and ROLLOF_15 on Annex A.
The same fix should be applied to all DVB-C capable tuners. Alternatively, we
should pu
Re: PATCH 05/13: 0005-TDA18271c2dd-Allow-frontend-to-set-DELSYS
Em 21-11-2011 19:06, Manu Abraham escreveu:
> patches/lmml_8518_patch_05_13_0005_tda18271c2dd_allow_frontend_to_set_delsys.patch
> Content-Type: text/plain; charset="utf-8"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Subject: PATCH 05/13: 0005-TDA18271c2dd-Allow-frontend-to-set-DELSYS
> Date: Mon, 21 Nov 2011 20:06:48 -
> From: Manu Abraham
> X-Patchwork-Id: 8518
> Message-Id:
>
> To: Linux Media Mailing List
> Cc: Mauro Carvalho Chehab ,
> Andreas Oberritter , Ralph Metzler
>
>
>
>
>
> >From 73c0b7c386beae392cff568e08914582ed6329d1 Mon Sep 17 00:00:00 2001
> From: Manu Abraham
> Date: Sat, 19 Nov 2011 21:01:03 +0530
> Subject: [PATCH 05/13] TDA18271c2dd: Allow frontend to set DELSYS, rather
> than querying fe->ops.info.type
>
> With any tuner that can tune to multiple delivery systems/standards, it does
> query fe->ops.info.type to determine frontend type and set the delivery
> system type. fe->ops.info.type can handle only 4 delivery systems, viz
> FE_QPSK,
> FE_QAM, FE_OFDM and FE_ATSC.
>
> Signed-off-by: Manu Abraham
> ---
> drivers/media/dvb/frontends/tda18271c2dd.c | 56
>
> 1 files changed, 56 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/media/dvb/frontends/tda18271c2dd.c
> b/drivers/media/dvb/frontends/tda18271c2dd.c
> index 1b1bf20..6077674 100644
> --- a/drivers/media/dvb/frontends/tda18271c2dd.c
> +++ b/drivers/media/dvb/frontends/tda18271c2dd.c
> @@ -1180,6 +1180,61 @@ static int set_params(struct dvb_frontend *fe,
> return status;
> }
>
> +static int set_state(struct dvb_frontend *fe, enum tuner_param param, struct
> tuner_state *tuner)
> +{
> + struct tda_state *state = fe->tuner_priv;
> + fe_delivery_system_t delsys = SYS_UNDEFINED;
> + u32 bandwidth = 0;
> + int status = 0;
> + int Standard = 0;
> +
> + if (param & DVBFE_TUNER_DELSYS)
> + delsys = tuner->delsys;
> + if (param & DVBFE_TUNER_FREQUENCY)
> + state->m_Frequency = tuner->frequency;
> + if (param & DVBFE_TUNER_BANDWIDTH)
> + bandwidth = tuner->bandwidth;
> +
> + switch (delsys) {
> + case SYS_DVBT:
> + switch (bandwidth) {
> + case 600:
> + Standard = HF_DVBT_6MHZ;
> + break;
> + case 700:
> + Standard = HF_DVBT_7MHZ;
> + break;
> + case 800:
> + Standard = HF_DVBT_8MHZ;
> + break;
> + }
> + break;
> + case SYS_DVBC_ANNEX_AC:
> + /*
> + * FIXME! API BUG! DVB-C ANNEX A & C are different
> + * This should have been simply DVBC_ANNEX_A
> + */
> + Standard = HF_DVBC_6MHZ;
API inconsistency were fixed by those two patches:
http://patchwork.linuxtv.org/patch/8501/
http://patchwork.linuxtv.org/patch/8503/
As I've commented on patch 4/13, bandwidth is not constant. It should be
calculated
based on roll-off and signal rate.
> + break;
> + default:
> + status = -EINVAL;
> + goto err;
> + }
> +
> + do {
> + status = RFTrackingFiltersCorrection(state, state->m_Frequency);
> + if (status < 0)
> + break;
> + status = ChannelConfiguration(state, state->m_Frequency,
> Standard);
> + if (status < 0)
> + break;
> +
> + msleep(state->m_SettlingTime); /* Allow AGC's to settle down */
> + } while (0);
> +err:
> + return status;
> +}
> +
> #if 0
> static int GetSignalStrength(s32 *pSignalStrength, u32 RFAgc, u32 IFAgc)
> {
> @@ -1221,6 +1276,7 @@ static struct dvb_tuner_ops tuner_ops = {
> .init = init,
> .sleep = sleep,
> .set_params= set_params,
> + .set_state = set_state,
> .release = release,
> .get_if_frequency = get_if_frequency,
> .get_bandwidth = get_bandwidth,
> --
> 1.7.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Query] V4L2 Integer (?) menu control
Hi Sakari, On 11/24/2011 09:57 PM, Sakari Ailus wrote: > Sylwester Nawrocki wrote: >> On 11/24/2011 09:50 AM, Sakari Ailus wrote: >>> >>> There is not currently, but I have patches for it. The issue is that I need >>> them myself but the driver I need them for isn't ready to be released yet. >>> And as usual, I assume others than vivo is required to show they're really >>> useful so I haven't sent them. >> >> That's great news. Then I might not need to do all the work on my own;) > > I hope mine will do. ;-) > > I'm working on 2.6.32 kernel (ouch!) so I haven't been able to test them > properly > yet. Please provide feedback on them if you find any issues. > >>> >>> Good that you asked so we won't end up writing essentially the same code >>> again. I'll try to send the patches today. >> >> All right, there is no rush. I was just looking around how to support the >> camera scene mode with m5mols sort of sensors. The scene mode is essentially >> a compilation of several different parameters, for some of which there are >> standard controls in V4L2 but for many there are not. > > I fully agree with this approach. Scene modes should not be implemented at the > level of the V4L2 API. Instead, the parameters that the scene modes consist of > must be shown separately on the V4L2 API, if that is the level of API they > belong > to. Depending on your camera stack control algorithms could reside in the > user > space, which I believe is however not the case with the M5-MOLS. No, with these hybrid camera devices the algorithms are built in their own ISP. And there is quite many advanced algorithms, e.g. auto focus/face detection that are difficult to control at the subdevice API level. > >> I've got a feeling the best way to handle this would be to create controls >> for each single parameter and then do a batch set from user space, and keep >> the scene mode mappings in user space. The only concern is there is a couple >> of ISP-specific parameters involved with that scene mode thing. Perhaps they >> just could be set initially to fixed values. > > Can you describe what kind of parameters this is about? Is there an issue in > just setting those using the ISP driver V4L2 subdev API? Please see struct m5mols_scenemode in file m5mols.h http://git.linuxtv.org/media_tree.git/blob/7e5219d18e93dd23e834a53b1ea73ead19cfeeb1:/drivers/media/video/m5mols/m5mols.h for a brief overview. I have also been preparing a list of the parameters and their exact meaning, but it's not ready yet. The issue is that the subdev API seems to low level for the device but it's the only API available at the user space ;) > > This makes your user space to depend both on the sensor and the ISP, but > there's > really no way around that if both do non-trivial hardware-specific things. I guess a dedicated library for the sensor itself is needed on top of subdevice API to be able to use advanced features. And even then subdevice/V4L2 API is a limitation. > > I think we need to further standardise image processing configuration such as > RGB-to-RGB matrices and gamma tables. This would make the ISP interfaces less > hardware specific. I guess first we need at least one more OMAP3 ISP like device driver in mainline to identify common features and design APIs for them. On the other hand gamma tables are also present in some embedded ISPs, e.g. in s5k6aafx IIRC. -- Regards, Sylwester -- 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 03/13: 0003-DVB-Allow-frontend-to-set-DELSYS-Modulation
Em 21-11-2011 19:06, Manu Abraham escreveu:
> With any tuner that can tune to multiple delivery systems/standards, it does
> query fe->ops.info.type to determine frontend type and set the delivery
> system type. fe->ops.info.type can handle only 4 delivery systems, viz
> FE_QPSK,
> FE_QAM, FE_OFDM and FE_ATSC.
>
> The change allows the tuner to be set to any delivery system specified in
> fe_delivery_system_t and any modulation as specified in fe_modulation_t,
> thereby simplification of issues.
>
> Signed-off-by: Manu Abraham
> ---
> drivers/media/dvb/dvb-core/dvb_frontend.h |4
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.h
> b/drivers/media/dvb/dvb-core/dvb_frontend.h
> index 67bbfa7..ec6e8e9 100644
> --- a/drivers/media/dvb/dvb-core/dvb_frontend.h
> +++ b/drivers/media/dvb/dvb-core/dvb_frontend.h
> @@ -113,6 +113,8 @@ enum tuner_param {
> DVBFE_TUNER_BANDWIDTH = (1 << 3),
> DVBFE_TUNER_REFCLOCK= (1 << 4),
> DVBFE_TUNER_IQSENSE = (1 << 5),
> + DVBFE_TUNER_DELSYS = (1 << 6),
> + DVBFE_TUNER_MODULATION = (1 << 7),
> DVBFE_TUNER_DUMMY = (1 << 31)
> };
>
> @@ -149,6 +151,8 @@ enum dvbfe_algo {
> };
>
> struct tuner_state {
> + fe_delivery_system_t delsys;
> + fe_modulation_t modulation;
> u32 frequency;
> u32 tunerstep;
> u32 ifreq;
Not sure about this patch.
Currently, tuners with newer standards just don't use the
dvb_frontend_parameters
passed into them, using instead fe->dtv_property_cache.
So, in the long term, it seems to make more sense to just change the
set_parameters callback parameters from:
static int set_params(struct dvb_frontend *fe,
struct dvb_frontend_parameters *params)
to:
static int set_params(struct dvb_frontend *fe)
or to explicitly pass the cache as an argument.
Regards,
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] V4L: omap1_camera: fix missing include
Hi Janusz On Fri, 25 Nov 2011, Janusz Krzysztofik wrote: > Otherwise compilation breaks with: > > drivers/media/video/omap1_camera.c:1535: error: 'THIS_MODULE' undeclared here > (not in a function) > ... > > after apparently no longer included recursively from other header files. > > Signed-off-by: Janusz Krzysztofik Thanks, will push with other 3.2-rc soc-camera fixes, when I find time to organise them... Thanks Guennadi > --- > drivers/media/video/omap1_camera.c |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/drivers/media/video/omap1_camera.c > b/drivers/media/video/omap1_camera.c > index e87ae2f..6a6cf38 100644 > --- a/drivers/media/video/omap1_camera.c > +++ b/drivers/media/video/omap1_camera.c > @@ -24,6 +24,7 @@ > #include > #include > #include > +#include > #include > #include > > -- > 1.7.3.4 > --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.
On Thursday 24 November 2011 18:37:02 Mauro Carvalho Chehab wrote: > Userspace applications that support av7110 can include the new linux/av7110.h > header. Other applications that support out-of-tree drivers can just have > their own copy of audio.h, osd.h and video.h. So, it won't break or prevent > existing applications to keep working. No way! Changes of the user-space API are not acceptable. If you do not believe that, ask Linux Torwalds! > The thing is that the media API presents two interfaces to control mpeg > decoders. > This is confusing, and, while one of them has active upstream developers > working > on it, adding new drivers and new features on it, the other API is not being > updated accordingly, and no new upstream drivers use it. The decoder API is as old as the DVB spec. NACK to any attempts to remove these files. Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- 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: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.
Hi,
no matter what that workshop discussed:
*** It is not acceptable to change the DVB kernel <-> user-space API! ***
Introduce whatever you want for V4L but do not touch the DVB drivers!
The av7110 driver is working for years and still in use.
I hereby NACK any attempt to remove dvb/*.h.
Nacked-by: Oliver Endriss
CU
Oliver
On Thursday 24 November 2011 14:39:09 Hans Verkuil wrote:
> From: Hans Verkuil
>
> Signed-off-by: Hans Verkuil
> ---
> fs/compat_ioctl.c | 41 +---
> include/linux/dvb/Kbuild |3 -
> include/linux/dvb/audio.h | 135 --
> include/linux/dvb/osd.h | 144 ---
> include/linux/dvb/video.h | 276
> -
> 5 files changed, 1 insertions(+), 598 deletions(-)
> delete mode 100644 include/linux/dvb/audio.h
> delete mode 100644 include/linux/dvb/osd.h
> delete mode 100644 include/linux/dvb/video.h
>
> diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
> index 51352de..71adea1 100644
> --- a/fs/compat_ioctl.c
> +++ b/fs/compat_ioctl.c
> @@ -105,10 +105,9 @@
>
> #include
>
> -#include
> +#include
> #include
> #include
> -#include
>
> #include
>
> @@ -196,32 +195,6 @@ static int do_video_stillpicture(unsigned int fd,
> unsigned int cmd,
> return err;
> }
>
> -struct compat_video_spu_palette {
> - int length;
> - compat_uptr_t palette;
> -};
> -
> -static int do_video_set_spu_palette(unsigned int fd, unsigned int cmd,
> - struct compat_video_spu_palette __user *up)
> -{
> - struct video_spu_palette __user *up_native;
> - compat_uptr_t palp;
> - int length, err;
> -
> - err = get_user(palp, &up->palette);
> - err |= get_user(length, &up->length);
> -
> - up_native = compat_alloc_user_space(sizeof(struct video_spu_palette));
> - err = put_user(compat_ptr(palp), &up_native->palette);
> - err |= put_user(length, &up_native->length);
> - if (err)
> - return -EFAULT;
> -
> - err = sys_ioctl(fd, cmd, (unsigned long) up_native);
> -
> - return err;
> -}
> -
> #ifdef CONFIG_BLOCK
> typedef struct sg_io_hdr32 {
> compat_int_t interface_id; /* [i] 'S' for SCSI generic (required)
> */
> @@ -1317,9 +1290,6 @@ COMPATIBLE_IOCTL(AUDIO_CLEAR_BUFFER)
> COMPATIBLE_IOCTL(AUDIO_SET_ID)
> COMPATIBLE_IOCTL(AUDIO_SET_MIXER)
> COMPATIBLE_IOCTL(AUDIO_SET_STREAMTYPE)
> -COMPATIBLE_IOCTL(AUDIO_SET_EXT_ID)
> -COMPATIBLE_IOCTL(AUDIO_SET_ATTRIBUTES)
> -COMPATIBLE_IOCTL(AUDIO_SET_KARAOKE)
> COMPATIBLE_IOCTL(DMX_START)
> COMPATIBLE_IOCTL(DMX_STOP)
> COMPATIBLE_IOCTL(DMX_SET_FILTER)
> @@ -1358,16 +1328,9 @@ COMPATIBLE_IOCTL(VIDEO_FAST_FORWARD)
> COMPATIBLE_IOCTL(VIDEO_SLOWMOTION)
> COMPATIBLE_IOCTL(VIDEO_GET_CAPABILITIES)
> COMPATIBLE_IOCTL(VIDEO_CLEAR_BUFFER)
> -COMPATIBLE_IOCTL(VIDEO_SET_ID)
> COMPATIBLE_IOCTL(VIDEO_SET_STREAMTYPE)
> COMPATIBLE_IOCTL(VIDEO_SET_FORMAT)
> -COMPATIBLE_IOCTL(VIDEO_SET_SYSTEM)
> -COMPATIBLE_IOCTL(VIDEO_SET_HIGHLIGHT)
> -COMPATIBLE_IOCTL(VIDEO_SET_SPU)
> -COMPATIBLE_IOCTL(VIDEO_GET_NAVI)
> -COMPATIBLE_IOCTL(VIDEO_SET_ATTRIBUTES)
> COMPATIBLE_IOCTL(VIDEO_GET_SIZE)
> -COMPATIBLE_IOCTL(VIDEO_GET_FRAME_RATE)
>
> /* joystick */
> COMPATIBLE_IOCTL(JSIOCGVERSION)
> @@ -1468,8 +1431,6 @@ static long do_ioctl_trans(int fd, unsigned int cmd,
> return do_video_get_event(fd, cmd, argp);
> case VIDEO_STILLPICTURE:
> return do_video_stillpicture(fd, cmd, argp);
> - case VIDEO_SET_SPU_PALETTE:
> - return do_video_set_spu_palette(fd, cmd, argp);
> }
>
> /*
> diff --git a/include/linux/dvb/Kbuild b/include/linux/dvb/Kbuild
> index f4dba86..f5aa137 100644
> --- a/include/linux/dvb/Kbuild
> +++ b/include/linux/dvb/Kbuild
> @@ -1,8 +1,5 @@
> -header-y += audio.h
> header-y += ca.h
> header-y += dmx.h
> header-y += frontend.h
> header-y += net.h
> -header-y += osd.h
> header-y += version.h
> -header-y += video.h
> diff --git a/include/linux/dvb/audio.h b/include/linux/dvb/audio.h
> deleted file mode 100644
> index d47bccd..000
> --- a/include/linux/dvb/audio.h
> +++ /dev/null
> @@ -1,135 +0,0 @@
> -/*
> - * audio.h
> - *
> - * Copyright (C) 2000 Ralph Metzler
> - * & Marcus Metzler
> - *for convergence integrated media GmbH
> - *
> - * This program is free software; you can redistribute it and/or
> - * modify it under the terms of the GNU General Lesser Public License
> - * as published by the Free Software Foundation; either version 2.1
> - * of the License, or (at your option) any later version.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> - * GNU General Public License for more details.
> - *
> - * You should have received a copy of the GNU Lesser General Public License
> - * along with this
Re: [RFCv2 PATCH 10/12] av7110: replace audio.h, video.h and osd.h by av7110.h.
Hi, no matter what that workshop discussed: *** It is not acceptable to change the DVB kernel <-> user-space API! *** Introduce whatever you want for V4L but do not touch the DVB drivers! The av7110 driver is working for years and still in use. I hereby NACK any attempt to remove dvb/*.h. Nacked-by: Oliver Endriss CU Oliver On Thursday 24 November 2011 14:39:07 Hans Verkuil wrote: > From: Hans Verkuil > > Create a new public header, av7110.h, that contains all the av7110 > specific audio, video and osd APIs that used to be defined in dvb/audio.h, > dvb/video.h and dvb/osd.h. These APIs are no longer part of DVBv5 but are > now av7110-specific. > > This decision was taken during the 2011 Prague V4L-DVB workshop. > > Ideally av7110 would be converted to use the replacement V4L2 MPEG > decoder API, but that's a huge job for such an old driver. > > Signed-off-by: Hans Verkuil > --- > drivers/media/dvb/ttpci/av7110.h |4 +- > include/linux/Kbuild |1 + > include/linux/av7110.h | 609 > ++ > 3 files changed, 611 insertions(+), 3 deletions(-) > create mode 100644 include/linux/av7110.h > > diff --git a/drivers/media/dvb/ttpci/av7110.h > b/drivers/media/dvb/ttpci/av7110.h > index d85b851..e36d6bd 100644 > --- a/drivers/media/dvb/ttpci/av7110.h > +++ b/drivers/media/dvb/ttpci/av7110.h > @@ -7,11 +7,9 @@ > #include > #include > > -#include > -#include > +#include > #include > #include > -#include > #include > #include > > diff --git a/include/linux/Kbuild b/include/linux/Kbuild > index 619b565..51bd25f 100644 > --- a/include/linux/Kbuild > +++ b/include/linux/Kbuild > @@ -68,6 +68,7 @@ header-y += audit.h > header-y += auto_fs.h > header-y += auto_fs4.h > header-y += auxvec.h > +header-y += av7110.h > header-y += ax25.h > header-y += b1lli.h > header-y += baycom.h > diff --git a/include/linux/av7110.h b/include/linux/av7110.h > new file mode 100644 > index 000..a192480 > --- /dev/null > +++ b/include/linux/av7110.h > @@ -0,0 +1,609 @@ > +/* > + * av7110.h > + * > + * Copyright (C) 2000 Marcus Metzler > + * & Ralph Metzler > + *for convergence integrated media GmbH > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public License > + * as published by the Free Software Foundation; either version 2.1 > + * of the License, or (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, > USA. > + * > + */ > + > +#ifndef _AV7110_API_H_ > +#define _AV7110_API_H_ > + > +#include > +#ifdef __KERNEL__ > +#include > +#else > +#include > +#include > +#endif > + > + > +/* av7110 video ioctls > + * > + * The DVB video device controls the MPEG2 video decoder of the av7110 DVB > + * hardware. It can be accessed through /dev/dvb/adapter0/video0. > + * > + * Note that the DVB video device only controls decoding of the MPEG video > + * stream, not its presentation on the TV or computer screen. On PCs this > + * is typically handled by an associated video4linux device, e.g. /dev/video, > + * which allows scaling and defining output windows. > + *Hi, no matter what that workshop discussed: *** It is not acceptable to change the DVB kernel <-> user-space API! *** Introduce whatever you want for V4L but do not touch the DVB drivers! The av7110 driver is working for years and still in use. I hereby NACK any attempt to remove dvb/*.h. Nacked-by: Oliver Endriss CU Oliver > + * Only one user can open the Video Device in O_RDWR mode. All other attempts > + * to open the device in this mode will fail and an error code will be > returned. > + * If the Video Device is opened in O_RDONLY mode, the only ioctl call that > can > + * be used is VIDEO_GET_STATUS. All other calls will return with an error > code. > + * > + * The write() system call can only be used if VIDEO_SOURCE_MEMORY is > selected > + * in the ioctl call VIDEO_SELECT_SOURCE. The data provided shall be in PES > + * format. If O_NONBLOCK is not specified the function will block until > buffer > + * space is available. The amount of data to be transferred is implied by > count. > + */ > + > +/** video_format_t > + * Used in the VIDEO_SET_FORMAT ioctl to tell the driver which aspect ratio > + * the output hardware (e.g. TV) has. It is also used in the data structures > + * video_status returned by VIDEO_GET_STATUS and video_event returned by > + * VIDEO_GET_EVENT which report
Re: [RFC PATCH 0/4] Replace VIDEO_COMMAND with VIDIOC_DECODER_CMD
Hi, no matter what that workshop discussed: *** It is not acceptable to change the DVB kernel <-> user-space API! *** The av7110 driver is working for years and still in use. I hereby NACK any attempt to remove dvb/audio.h or dvb/video.h. Nacked-by: Oliver Endriss On Wednesday 23 November 2011 12:12:32 Hans Verkuil wrote: > During the 2011 workshop we discussed replacing the decoder commands in > include/linux/dvb/video.h and audio.h by a proper V4L2 API. > > This patch series is the first phase of that. It adds new > VIDIOC_(TRY_)DECODER_CMD > ioctls to the V4L2 API. These are identical to the VIDEO_(TRY_)COMMAND from > dvb/video.h, but the names of the fields and defines now conform to the V4L2 > API conventions. > > Documentation has been added and ivtv (the only V4L2 driver that used > VIDEO_COMMAND) > has been adapted to support the new V4L2 API. > > I do have one question for Mauro: what do you want to do with video.h? Should > it be > removed altogether eventually? > > Some of the commands defined there aren't used by any driver (e.g. > VIDEO_GET_NAVI), > some are specific to the av7110 driver (e.g. VIDEO_STILLPICTURE), some are > specific > to ivtv (VIDEO_COMMAND) and some are used by both ivtv and av7110 (e.g. > VIDEO_PLAY). > > My proposal would be to: > > 1) remove anything that is not used by any driver from audio.h and video.h > 2) move av7110 specific stuff to a new linux/av7110.h header > 3) move ivtv specific stuff to the linux/ivtv.h header > 4) shared code should be moved to the new linux/av7110.h header and also > copied >to linux/ivtv.h. The ivtv version will rename the names (e.g. VIDEO_ > becomes >IVTV_) but is otherwise unchanged to preserve the ABI. Comments are added >on how to convert the legacy ioctls to standard V4L2 API in applications. >Perhaps these legacy ioctls in ivtv can even be removed in a few years > time. > 5) remove linux/dvb/audio.h and video.h. > > What do you think, Mauro? > > Regards, > > Hans -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- 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] V4L: omap1_camera: fix missing include
Otherwise compilation breaks with: drivers/media/video/omap1_camera.c:1535: error: 'THIS_MODULE' undeclared here (not in a function) ... after apparently no longer included recursively from other header files. Signed-off-by: Janusz Krzysztofik --- drivers/media/video/omap1_camera.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/omap1_camera.c b/drivers/media/video/omap1_camera.c index e87ae2f..6a6cf38 100644 --- a/drivers/media/video/omap1_camera.c +++ b/drivers/media/video/omap1_camera.c @@ -24,6 +24,7 @@ #include #include #include +#include #include #include -- 1.7.3.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: [RFC/PATCH 2/3] v4l: Document integer menu controls
On 11/24/2011 05:12 PM, Sakari Ailus wrote: > Signed-off-by: Sakari Ailus > --- > Documentation/DocBook/media/v4l/compat.xml | 10 + > Documentation/DocBook/media/v4l/v4l2.xml |7 > .../DocBook/media/v4l/vidioc-queryctrl.xml | 39 > +++- > 3 files changed, 54 insertions(+), 2 deletions(-) > > diff --git a/Documentation/DocBook/media/v4l/compat.xml > b/Documentation/DocBook/media/v4l/compat.xml > index b68698f..569efd1 100644 > --- a/Documentation/DocBook/media/v4l/compat.xml > +++ b/Documentation/DocBook/media/v4l/compat.xml > @@ -2379,6 +2379,16 @@ that used it. It was originally scheduled for removal > in 2.6.35. > > > > + > +V4L2 in Linux 3.3 > + > + > + Added integer menus, the new type will be > + V4L2_CTRL_TYPE_INTEGER_MENU. > + > + > + > + > > Relation of V4L2 to other Linux multimedia APIs > > diff --git a/Documentation/DocBook/media/v4l/v4l2.xml > b/Documentation/DocBook/media/v4l/v4l2.xml > index 2ab365c..affe1ba 100644 > --- a/Documentation/DocBook/media/v4l/v4l2.xml > +++ b/Documentation/DocBook/media/v4l/v4l2.xml > @@ -128,6 +128,13 @@ structs, ioctls) must be noted in more detail in the > history chapter > applications. --> > > > + 3.3 > + 2011-11-24 > + sa > + Added V4L2_CTRL_TYPE_INTEGER_MENU. > + > + > + > 3.2 > 2011-08-26 > hv > diff --git a/Documentation/DocBook/media/v4l/vidioc-queryctrl.xml > b/Documentation/DocBook/media/v4l/vidioc-queryctrl.xml > index 0ac0057..049cd46 100644 > --- a/Documentation/DocBook/media/v4l/vidioc-queryctrl.xml > +++ b/Documentation/DocBook/media/v4l/vidioc-queryctrl.xml > @@ -215,11 +215,12 @@ the array to zero. > > > structv4l2_querymenu > - > + > &cs-str; > > > __u32 > + > id > Identifies the control, set by the application > from the respective&v4l2-queryctrl; > @@ -227,18 +228,38 @@ from the respective&v4l2-queryctrl; > > > __u32 > + > index > Index of the menu item, starting at zero, set by > the application. > > > + union > + > + > + > + > + > + > __u8 > name[32] > Name of the menu item, a NUL-terminated ASCII > -string. This information is intended for the user. > +string. This information is intended for the user. This field is valid > +forV4L2_CTRL_FLAG_MENU type controls. > + > + > + > + __s64 > + value > + > + Value of the integer menu item. This field is valid for > +V4L2_CTRL_FLAG_INTEGER_MENU type > + controls. > + > > > __u32 > + > reserved > Reserved for future extensions. Drivers must set > the array to zero. > @@ -292,6 +313,20 @@ the menu items can be enumerated with the > VIDIOC_QUERYMENU ioctl. > > > + V4L2_CTRL_TYPE_INTEGER_MENU > + ≥ 0 > + 1 > + N-1 > + > + The control has a menu of N choices. The names of the > + menu items can be enumerated with the Shouldn't it be something along the lines of "The integer values of the menu items can be enumerated..." ? > +VIDIOC_QUERYMENU ioctl. This is > + similar toV4L2_CTRL_TYPE_MENU > + except that instead of integers, the menu items are > + signed 64-bit integers. > + > + > + > V4L2_CTRL_TYPE_BITMASK > 0 > n/a -- Regards, Sylwester -- 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 PULL FOR 3.2] misc small changes, mostly get/set IF related
On 11/24/2011 09:58 PM, Mauro Carvalho Chehab wrote: Em 13-11-2011 17:20, Antti Palosaari escreveu: Mauro, and these too for 3.3. Sorry about mistakes. In fact, those 3 patches seemed to be good for 3.2: 576b849 [media] mxl5007t: fix reg read d7d89dc [media] tda18218: fix 6 MHz default IF frequency ff83bd8 [media] af9015: limit I2C access to keep FW happy So, I've backported d7d89dc to 3.2, and applied there. the others, I've added for 3.3. You could put mxl5007t and tda18218. But as I changed tda18218 to support .get_if_frequency() just before that fix and it touches same code lines, it will not apply unless you do some hand editing or apply tda18218 get_if_frequency() patch too. DO *NOT* push af9015 I2C patch to the 3.2. I see there could be potential problems if there is heavy demodulator I2C traffic since it forces to wait some I2C related tasks. I suspect that could lead bad situation when there is more traffic we can handle due to I2C access waiting coming from patch. I have optimized af9013 I2C load, reduced it rather much switching multibyte I2C where possible and running statistic polls using timers in backround. Now it returns all statistics from cache and not make any statistics queries directly when userspace app is asking. After my af9013 optimizations are ready those could be put to master, which will happen likely 3.3 schedule. It is absolutely too risky put that single patch to 3.2. regards Antti -- http://palosaari.fi/ -- 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/PATCH 0/3] 64-bit integer menus
Hi Sakari, thanks for the patches. On 11/24/2011 05:12 PM, Sakari Ailus wrote: > Hi all, > > This patchset, which I'm sending as RFC since it has not been really tested > (including compiling the vivi patch), adds 64-bit integer menu controls. The > control items in the integer menu are just like in regular menus but they > are 64-bit integers instead of strings. > > I'm also pondering whether to assign 1 to ctrl->step for menu type controls > as well but haven't checked what may have been the original reason to > implement it as it is now implemented. > > The reason why I don't use a union for qmenu and qmenu_int in > v4l2_ctrl_config is that a lot of drivers use that field in the initialiser > and GCC< 4.6 does not support initialisers with anonymous unions. > > Similar union is created in v4l2_querymenu but I do not see this as a > problem since I do not expect initialisers to be used with this field in the > user space code. > > Comments and questions are welcome. I've gone briefly through the patches and they seem to realize exactly what I needed. I think we've discussed the integer menu controls during the Cambourne meeting, however I wasn't sure yesterday if it was just this. I'll try and implement some of the controls for m5mols based on your patches. Cannot guarantee I'll manage to have something ready for 3.3, I need to finish a few other things before I get to this. -- Thanks, Sylwester -- 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 request for 3.2 (fixes 'n' features)
Em 24-11-2011 11:32, Mauro Carvalho Chehab escreveu: > Em 24-11-2011 07:26, Patrick Boettcher escreveu: >> Hi Mauro, >> >> On Tue, 4 Oct 2011, Patrick Boettcher wrote: >> >>> Hi Mauro, >>> >>> if it's not too late for 3.2 could you please pull from >>> >>> git://linuxtv.org/pb/media_tree.git staging/for_v3.2 >>> >>> for >>> >>> [media] dib9090: limit the I2C speed [media] dib8096P: add the reference >>> board [media] add the support for DiBcom [media] dib7090: add the reference >>> board [media] DiB8000: improve the tuning and the SNR monitoring >>> [media] DiBcom: correct warnings >>> [media] dib7090: add the reference board TFE7090E >>> [media] dib7000p/dib0090: update the driver >> >> I think this PULL request got lost. (as usual for my pull-requests :( ). > > Yes, I didn't get your pull request. Now that we're using patchwork, to also > track pull > requests, it is easy for you to check if the pull request is on my queue. > Just take a > look at http://patchwork.linuxtv.org. > > It should be noticed that patchwork relies on the way that git request-pull > formats the > message: > > $ git request-pull HEAD^1 . > The following changes since commit db9bc660cf4d1a09565f5db2bab9d3b86e3e32a5: > > [media] ir-rc6-decoder: Support RC6-6A variable length data (2011-11-23 > 22:23:15 -0200) > > are available in the git repository at: > . staging/for_v3.3 > > Dan Carpenter (1): > [media] V4L: mt9t112: use after free in mt9t112_probe() > > drivers/media/video/mt9t112.c |4 +++- > 1 files changed, 3 insertions(+), 1 deletions(-) > > It basically seeks for "The following...at: " part of the > message. If found, > it will add it at its repository, like: > > http://patchwork.linuxtv.org/patch/8279/ > >> It was meant for 3.2 and was sent in advance. >> >> Do you think you will get it in? > > We can get the fixes, and new board additions for 3.2, but driver updates > should > go to 3.3. The fixes there seems to be linked to the driver improvements, and they're not trivial, so I've merged them for 3.3. If is there any patch that is just a fix for the existing code, please point me and I'll add for 3.2. Regards, 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
AverTV Volar HD Pro scanning problems
Hello, I use this device 07ca:a835 AVerMedia Technologies, Inc. with a 3.1.2 kernel (x86_64). TV can be played just fine in Kaffeine, but scanning does not work (tried with kaffeine, scan). One has to obtain the channel information from elsewhere, since scanning ends with the following errors in dmesg: af9035: recv bulk message failed:-110 af9033: I2C read failed reg:0047 af9035: recv bulk message failed:-110 af9033: I2C read failed reg:0045 * Attempts to disable USB autosuspend (using the usbcore parameter and/or laptop-mode-tools) don't change anything. * Failures are less likely (occur later during the scan) if the device is plugged into a USB 3.0 port. How can I make scanning work? Is there a Git branch I could try? Thank you in advance for your hints. :-) Andrej P. S. The dmesg output after plugging in the device: usb 4-1.2: new high speed USB device number 6 using ehci_hcd dvb-usb: found a 'Avermedia AverTV Volar HD & HD PRO (A835)' in cold state, will try to load a firmware dvb-usb: downloading firmware from file 'dvb-usb-af9035-01.fw' dvb-usb: found a 'Avermedia AverTV Volar HD & HD PRO (A835)' in warm state. dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. DVB: registering new adapter (Avermedia AverTV Volar HD & HD PRO (A835)) af9033: firmware version: LINK:11.15.10.0 OFDM:5.48.10.0 DVB: registering adapter 0 frontend 0 (Afatech AF9033 DVB-T)... tda18218: NXP TDA18218HN successfully identified. IR keymap rc-avermedia-rm-ks not found Registered IR keymap rc-empty input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1d.0/usb4/4-1/4-1.2/rc/rc3/input19 rc3: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1d.0/usb4/4-1/4-1.2/rc/rc3 dvb-usb: schedule remote query interval to 400 msecs. dvb-usb: Avermedia AverTV Volar HD & HD PRO (A835) successfully initialized and connected. smime.p7s Description: Elektronický podpis S/MIME
[PATCH] MAINTAINERS: Update media entries
Now that we've created a /drivers/staging/media, put it together with /drivers/media. Also, added there a missing entry for the Media API spec. Signed-off-by: Mauro Carvalho Chehab --- MAINTAINERS |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index e839b95..273b049 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4234,7 +4234,9 @@ T:git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git S: Maintained F: Documentation/dvb/ F: Documentation/video4linux/ +F: Documentation/DocBook/media/ F: drivers/media/ +F: drivers/staging/media/ F: include/media/ F: include/linux/dvb/ F: include/linux/videodev*.h -- 1.7.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Query] V4L2 Integer (?) menu control
Hi Sylwester, Sylwester Nawrocki wrote: Thank you all for the comments. On 11/24/2011 09:50 AM, Sakari Ailus wrote: Hi Sylwester, There is not currently, but I have patches for it. The issue is that I need them myself but the driver I need them for isn't ready to be released yet. And as usual, I assume others than vivo is required to show they're really useful so I haven't sent them. That's great news. Then I might not need to do all the work on my own;) I hope mine will do. ;-) I'm working on 2.6.32 kernel (ouch!) so I haven't been able to test them properly yet. Please provide feedback on them if you find any issues. Good that you asked so we won't end up writing essentially the same code again. I'll try to send the patches today. All right, there is no rush. I was just looking around how to support the camera scene mode with m5mols sort of sensors. The scene mode is essentially a compilation of several different parameters, for some of which there are standard controls in V4L2 but for many there are not. I fully agree with this approach. Scene modes should not be implemented at the level of the V4L2 API. Instead, the parameters that the scene modes consist of must be shown separately on the V4L2 API, if that is the level of API they belong to. Depending on your camera stack control algorithms could reside in the user space, which I believe is however not the case with the M5-MOLS. I've got a feeling the best way to handle this would be to create controls for each single parameter and then do a batch set from user space, and keep the scene mode mappings in user space. The only concern is there is a couple of ISP-specific parameters involved with that scene mode thing. Perhaps they just could be set initially to fixed values. Can you describe what kind of parameters this is about? Is there an issue in just setting those using the ISP driver V4L2 subdev API? This makes your user space to depend both on the sensor and the ISP, but there's really no way around that if both do non-trivial hardware-specific things. I think we need to further standardise image processing configuration such as RGB-to-RGB matrices and gamma tables. This would make the ISP interfaces less hardware specific. Kind regards, -- Sakari Ailus sakari.ai...@iki.fi -- 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 RESEND] davinci: dm646x: move vpif related code to driver core header from platform
Em 24-11-2011 16:22, Nori, Sekhar escreveu: > Hi Mauro, > > On Thu, Nov 24, 2011 at 23:35:24, Mauro Carvalho Chehab wrote: >> Em 12-11-2011 13:06, Manjunath Hadli escreveu: >>> move vpif related code for capture and display drivers >>> from dm646x platform header file to vpif_types.h as these definitions >>> are related to driver code more than the platform or board. >>> >>> Signed-off-by: Manjunath Hadli >> >> Manju, >> >> Why are you re-sending a patch? >> >> My understanding is that you're maintaining the davinci patches, so it is >> up to you to put those patches on your tree and send me a pull request when >> they're done. So, please, don't pollute the ML re-sending emails that >> are for yourself to handle. > > Since this particular patch touches arch/arm/mach-davinci > as well as drivers/media/video, the plan was to queue the > patch through ARM tree with your Ack. We did not get your > ack the last time around[1] so it was resent. > > Do let me know if your ack is not needed. > > Thanks, > Sekhar > > [1] > http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg21840.html Hmm.. I missed this email, but just re-sending it without request my ACK doesn't help much ;) If this ever happens again, next time the better is to forward me the patch again, on an email asking for my ack. With regards to the patch: Acked-by: Mauro Carvalho Chehab Regards, 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: [GIT PULL FOR 3.2] misc small changes, mostly get/set IF related
Em 13-11-2011 17:20, Antti Palosaari escreveu: > Mauro, > and these too for 3.3. Sorry about mistakes. In fact, those 3 patches seemed to be good for 3.2: 576b849 [media] mxl5007t: fix reg read d7d89dc [media] tda18218: fix 6 MHz default IF frequency ff83bd8 [media] af9015: limit I2C access to keep FW happy So, I've backported d7d89dc to 3.2, and applied there. the others, I've added for 3.3. > > regards > Antti > > On 11/13/2011 09:12 PM, Antti Palosaari wrote: >> Moro >> >> These patches are rather small enchantments and should not have any >> visible effect. >> >> mxl5007t change is that register read fix I have mentioned earlier. Reg >> read is used only for checking chip ID and even if ID is not detected >> correctly it will still work. So no functional changes. >> >> Antti >> >> The following changes since commit >> df5f76dfef9bfaec1ff27d0a60a57a773bf87f0f: >> >> af9015: limit I2C access to keep FW happy (2011-11-13 03:33:30 +0200) >> >> are available in the git repository at: >> git://linuxtv.org/anttip/media_tree.git af9015 >> >> Antti Palosaari (12): >> tda18218: implement .get_if_frequency() >> tda18218: fix 6 MHz default IF frequency >> af9013: use .get_if_frequency() when possible >> mt2060: implement .get_if_frequency() >> qt1010: implement .get_if_frequency() >> tda18212: implement .get_if_frequency() >> tda18212: round IF frequency to close hardware value >> cxd2820r: switch to .get_if_frequency() >> cxd2820r: check bandwidth earlier for DVB-T/T2 >> mxl5007t: fix reg read >> ce6230: remove experimental from Kconfig >> ce168: remove experimental from Kconfig >> >> drivers/media/common/tuners/mt2060.c | 9 +++- >> drivers/media/common/tuners/mxl5007t.c | 3 +- >> drivers/media/common/tuners/qt1010.c | 9 +++- >> drivers/media/common/tuners/tda18212.c | 17 +++- >> drivers/media/common/tuners/tda18218.c | 18 ++- >> drivers/media/common/tuners/tda18218_priv.h | 2 + >> drivers/media/dvb/dvb-usb/Kconfig | 4 +- >> drivers/media/dvb/dvb-usb/anysee.c | 7 --- >> drivers/media/dvb/frontends/af9013.c | 43 -- >> drivers/media/dvb/frontends/cxd2820r.h | 13 -- >> drivers/media/dvb/frontends/cxd2820r_c.c | 13 +- >> drivers/media/dvb/frontends/cxd2820r_t.c | 55 +-- >> drivers/media/dvb/frontends/cxd2820r_t2.c | 62 +++ >> drivers/media/video/em28xx/em28xx-dvb.c | 7 --- >> 14 files changed, 140 insertions(+), 122 deletions(-) >> >> > > -- 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
BUG: scheduling while atomic: kworker/0:0/0/0x00000100
Hi, I have setup a new vdr with yavdr 0.4 with one TT full-featured DVB-S card (S2300) and one Mystique SaTiX-S2 Sky Xpress dual. As soon as I pause the video I get endless reports like the one in the headline and the vdr is dead. Because of the new SaTiX card I had to update the DVB drivers to the latest media-tree. I tried the yavdr kernel 2.6.38-12, a vanilla 3.0.9 kernel and I also tested the DVB driver from dvbsky.net on top of vanilla 3.0.9. I always get the same result - working perfectly until I press pause. In the log below schedule is called by play_video_cb (dvb-ttpci). Any help is appreciated. /Stefan LOG: Nov 22 20:19:23 vdr4 kernel: [ 1881.295798] BUG: scheduling while atomic: kworker/0:0/0/0x0100 Nov 22 20:19:23 vdr4 kernel: [ 1881.295806] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek speedstep_lib nfsd exportfs nfs lockd fscache auth_rpcgss nfs_acl rc_dvbsky ds3000 lnbp21 sunrpc stv0299 cx25840 ir_lirc_codec lirc_dev snd_hda_intel snd_hda_codec ir_mce_kbd_decoder snd_hwdep ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder ir_nec_decoder cx23885 rc_core snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event cx2341x videobuf_dvb v4l2_common snd_seq dvb_ttpci dvb_core saa7146_vv snd_timer snd_seq_device snd mxm_wmi saa7146 videodev soundcore videobuf_dma_sg videobuf_core v4l2_compat_ioctl32 ttpci_eeprom psmouse snd_page_alloc serio_raw video btcx_risc tveeprom edac_core edac_mce_amd k8temp shpchp i2c_nforce2 lp parport floppy firewire_ohci firewire_core crc_itu_t forcedeth ahci libahci Nov 22 20:19:23 vdr4 kernel: [ 1881.295863] CPU 1 Nov 22 20:19:23 vdr4 kernel: [ 1881.295864] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek speedstep_lib nfsd exportfs nfs lockd fscache auth_rpcgss nfs_acl rc_dvbsky ds3000 lnbp21 sunrpc stv0299 cx25840 ir_lirc_codec lirc_dev snd_hda_intel snd_hda_codec ir_mce_kbd_decoder snd_hwdep ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder ir_nec_decoder cx23885 rc_core snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event cx2341x videobuf_dvb v4l2_common snd_seq dvb_ttpci dvb_core saa7146_vv snd_timer snd_seq_device snd mxm_wmi saa7146 videodev soundcore videobuf_dma_sg videobuf_core v4l2_compat_ioctl32 ttpci_eeprom psmouse snd_page_alloc serio_raw video btcx_risc tveeprom edac_core edac_mce_amd k8temp shpchp i2c_nforce2 lp parport floppy firewire_ohci firewire_core crc_itu_t forcedeth ahci libahci Nov 22 20:19:23 vdr4 kernel: [ 1881.295910] Nov 22 20:19:23 vdr4 kernel: [ 1881.295913] Pid: 0, comm: kworker/0:0 Not tainted 3.1.0-media+ #1 System manufacturer System Product Name/M3N78-EM Nov 22 20:19:23 vdr4 kernel: [ 1881.295919] RIP: 0010:[] [] native_safe_halt+0xb/0x10 Nov 22 20:19:23 vdr4 kernel: [ 1881.295928] RSP: 0018:88007432fe88 EFLAGS: 0246 Nov 22 20:19:23 vdr4 kernel: [ 1881.295931] RAX: RBX: 8101aa95 RCX: Nov 22 20:19:23 vdr4 kernel: [ 1881.295934] RDX: RSI: 88007432fec4 RDI: Nov 22 20:19:23 vdr4 kernel: [ 1881.295936] RBP: 88007432fe88 R08: R09: Nov 22 20:19:23 vdr4 kernel: [ 1881.295939] R10: R11: R12: 880077c91200 Nov 22 20:19:23 vdr4 kernel: [ 1881.295941] R13: 00ff8800 R14: R15: 880071760058 Nov 22 20:19:23 vdr4 kernel: [ 1881.295945] FS: 7fe326c31740() GS:880077c8() knlGS: Nov 22 20:19:23 vdr4 kernel: [ 1881.295948] CS: 0010 DS: ES: CR0: 8005003b Nov 22 20:19:23 vdr4 kernel: [ 1881.295951] CR2: 7fe2fc5efac4 CR3: 71d26000 CR4: 06e0 Nov 22 20:19:23 vdr4 kernel: [ 1881.295953] DR0: DR1: DR2: Nov 22 20:19:23 vdr4 kernel: [ 1881.295956] DR3: DR6: 0ff0 DR7: 0400 Nov 22 20:19:23 vdr4 kernel: [ 1881.295959] Process kworker/0:0 (pid: 0, threadinfo 88007432e000, task 88007433) Nov 22 20:19:23 vdr4 kernel: [ 1881.295962] Stack: Nov 22 20:19:23 vdr4 kernel: [ 1881.295964] 88007432fea8 8101b901 88007432fec4 81abccc0 Nov 22 20:19:23 vdr4 kernel: [ 1881.295968] 88007432fed8 8101b9fd 88007432fec8 7432e000 Nov 22 20:19:23 vdr4 kernel: [ 1881.295973] 88007432e000 81abccc0 88007432ff18 81012276 Nov 22 20:19:23 vdr4 kernel: [ 1881.295977] Call Trace: Nov 22 20:19:23 vdr4 kernel: [ 1881.295983] [] default_idle+0x41/0xe0 Nov 22 20:19:23 vdr4 kernel: [ 1881.295987] [] amd_e400_idle+0x5d/0x120 Nov 22 20:19:23 vdr4 kernel: [ 1881.295991] [] cpu_idle+0xd6/0x110 Nov 22 20:19:23 vdr4 kernel: [ 1881.295997] [] start_secondary+0x1e0/0x1e7 Nov 22 20:19:23 vdr4 kernel: [ 1881.295999] Code: 55 48 89 e5 66 66 66 66 90 fa c9 c3 0f 1f 40 00 55 48 89 e5 66 66 66 66 90 fb c9 c3 0f 1f 40 00 55 48 89 e5 66 66 66 66 90 fb f4 c3 0f 1f 00 5
Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.
On Fri, Nov 25, 2011 at 12:17 AM, Mauro Carvalho Chehab wrote: > Em 24-11-2011 16:13, Manu Abraham escreveu: >> On Thu, Nov 24, 2011 at 11:38 PM, Mauro Carvalho Chehab >> wrote: >>> Em 24-11-2011 16:01, Manu Abraham escreveu: On Thu, Nov 24, 2011 at 11:14 PM, Hans Verkuil wrote: > On Thursday, November 24, 2011 18:08:05 Andreas Oberritter wrote: >> Don't break existing Userspace APIs for no reason! It's OK to add the >> new API, but - pretty please - don't just blindly remove audio.h and >> video.h. They are in use since many years by av7110, out-of-tree drivers >> *and more importantly* by applications. Yes, I know, you'd like to see >> those out-of-tree drivers merged, but it isn't possible for many >> reasons. And even if they were merged, you'd say "Port them and your >> apps to V4L". No! That's not an option. > > I'm not breaking anything. All apps will still work. > > One option (and it depends on whether people like it or not) is to have > audio.h, video.h and osd.h just include av7110.h and add a #warning > that these headers need to be replaced by the new av7110.h. That won't work with other non av7110 hardware. >>> >>> There isn't any non-av7110 driver using it at the Kernel. Anyway, we can put >>> a warning at the existing headers as-is, for now, putting them to be removed >>> for a new kernel version, like 3.4. >> >> >> No, that's not an option. The to-be merged saa716x driver depends on it. > > If the driver is not merged yet, it can be changed. A DVB alone device shouldn't use V4L, while an existing interface exists. I have no plans of porting the driver to use DVB and V4L, for DVB alone operations. -- 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: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.
On Fri, Nov 25, 2011 at 12:17 AM, Mauro Carvalho Chehab wrote: > Em 24-11-2011 16:13, Manu Abraham escreveu: >> On Thu, Nov 24, 2011 at 11:38 PM, Mauro Carvalho Chehab >> wrote: >>> Em 24-11-2011 16:01, Manu Abraham escreveu: On Thu, Nov 24, 2011 at 11:14 PM, Hans Verkuil wrote: > On Thursday, November 24, 2011 18:08:05 Andreas Oberritter wrote: >> Don't break existing Userspace APIs for no reason! It's OK to add the >> new API, but - pretty please - don't just blindly remove audio.h and >> video.h. They are in use since many years by av7110, out-of-tree drivers >> *and more importantly* by applications. Yes, I know, you'd like to see >> those out-of-tree drivers merged, but it isn't possible for many >> reasons. And even if they were merged, you'd say "Port them and your >> apps to V4L". No! That's not an option. > > I'm not breaking anything. All apps will still work. > > One option (and it depends on whether people like it or not) is to have > audio.h, video.h and osd.h just include av7110.h and add a #warning > that these headers need to be replaced by the new av7110.h. That won't work with other non av7110 hardware. >>> >>> There isn't any non-av7110 driver using it at the Kernel. Anyway, we can put >>> a warning at the existing headers as-is, for now, putting them to be removed >>> for a new kernel version, like 3.4. >> >> >> No, that's not an option. The to-be merged saa716x driver depends on it. > > If the driver is not merged yet, it can be changed. > >> A DVB alone device need not depend V4L2 for it's operation. > > Why not? DVB drivers with IR should implement the input/event/IR API. DVB > drivers with net > should implement the Linux Network API. A DVB device having DVB alone associated with it, I see no reason for it to be using V4L framework, while that same framework exists within DVB, just because someone has created some artificial reasons to remove it and put it to V4L. That's so wicked and full of politics. -- 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: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Thu Nov 24 19:00:29 CET 2011 git hash:4a5006f68d6b336564eb1e4cbb1f66d234958889 gcc version: i686-linux-gcc (GCC) 4.6.1 host hardware:x86_64 host os: 3.1-2.slh.1-amd64 linux-git-arm-eabi-enoxys: ERRORS linux-git-arm-eabi-omap: ERRORS linux-git-armv5-ixp: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2-rc1-x86_64: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.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: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.
Em 24-11-2011 16:13, Manu Abraham escreveu: > On Thu, Nov 24, 2011 at 11:38 PM, Mauro Carvalho Chehab > wrote: >> Em 24-11-2011 16:01, Manu Abraham escreveu: >>> On Thu, Nov 24, 2011 at 11:14 PM, Hans Verkuil wrote: On Thursday, November 24, 2011 18:08:05 Andreas Oberritter wrote: > Don't break existing Userspace APIs for no reason! It's OK to add the > new API, but - pretty please - don't just blindly remove audio.h and > video.h. They are in use since many years by av7110, out-of-tree drivers > *and more importantly* by applications. Yes, I know, you'd like to see > those out-of-tree drivers merged, but it isn't possible for many > reasons. And even if they were merged, you'd say "Port them and your > apps to V4L". No! That's not an option. I'm not breaking anything. All apps will still work. One option (and it depends on whether people like it or not) is to have audio.h, video.h and osd.h just include av7110.h and add a #warning that these headers need to be replaced by the new av7110.h. >>> >>> >>> That won't work with other non av7110 hardware. >> >> There isn't any non-av7110 driver using it at the Kernel. Anyway, we can put >> a warning at the existing headers as-is, for now, putting them to be removed >> for a new kernel version, like 3.4. > > > No, that's not an option. The to-be merged saa716x driver depends on it. If the driver is not merged yet, it can be changed. > A DVB alone device need not depend V4L2 for it's operation. Why not? DVB drivers with IR should implement the input/event/IR API. DVB drivers with net should implement the Linux Network API. There is nothing wrong on using the ALSA API for audio and the V4L2 API for video, as both API fits the needs for decoding audio and video streams, and new features could be added there when needed. Duplicated API's that become legacy are removed with time. Just to mention two notable cases, this happened with the old audio stack (OSS), with the old Wireless stack. Do you have any issues that needs to be addressed by the V4L2 API for it to fit on your needs? > Also, it doesn't > make any sense to have device specific headers to be used by an application, > when drivers share more than one commonality. The only in-kernel driver using audio/video/osd is av7110. There are some other cases on driver-specific API's. The bttv and ivtv drivers used to have it. Their private API's were gradually replaced by other API's that are more flexible and become standardized. In some cases, the same API that used to be private were moved to the core API Regards, 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: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.
On Thu, Nov 24, 2011 at 11:55 PM, Mauro Carvalho Chehab wrote: > Em 24-11-2011 16:07, Andreas Oberritter escreveu: >> On 24.11.2011 18:58, Mauro Carvalho Chehab wrote: >>> Em 24-11-2011 15:51, Andreas Oberritter escreveu: On 24.11.2011 18:44, Hans Verkuil wrote: > On Thursday, November 24, 2011 18:08:05 Andreas Oberritter wrote: >> Don't break existing Userspace APIs for no reason! It's OK to add the >> new API, but - pretty please - don't just blindly remove audio.h and >> video.h. They are in use since many years by av7110, out-of-tree drivers >> *and more importantly* by applications. Yes, I know, you'd like to see >> those out-of-tree drivers merged, but it isn't possible for many >> reasons. And even if they were merged, you'd say "Port them and your >> apps to V4L". No! That's not an option. > > I'm not breaking anything. All apps will still work. > > One option (and it depends on whether people like it or not) is to have > audio.h, video.h and osd.h just include av7110.h and add a #warning > that these headers need to be replaced by the new av7110.h. > > And really remove them at some point in the future. > > But the important thing to realize is that the ABI hasn't changed (unless > I made a mistake somewhere). So why don't you just leave the headers where they are and add a notice about the new V4L API as a comment? What you proposed breaks compilation. If you add a warning, it breaks compilation for programs compiled with -Werror. Both are regressions. >>> >>> I don't mind doing it for 3.3 kernel, and add a note at >>> Documentation/feature-removal-schedule.txt that the >>> headers will go away on 3.4. This should give distributions >>> and app developers enough time to prevent build failures, and >>> prepare for the upcoming changes. >> >> Are you serious? >> >> Breaking things that worked well for many years - for an artificially >> invented reason - is so annoying, I can't even find the words to express >> how much this sucks. > > Andreas, > > All the in-kernel API's are there to support in-kernel drivers. > > Out of tree drivers can do whatever they want. As you likely know, several STB > vendors have their own API's. > > Some use some variants of DVBv3 or DVBv5, and some use their own proprietary > API's, that are even incompatible with DVB (and some even provide both). > > Even the ones that use DVBv3 (or v5) have their own implementation that > diverges > from the upstream one. > > Provided that such vendors don't violate the Kernel GPLv2 license where it > applies, > they're free do do whatever they want, forking the DVB API, or creating their > own > stacks. > > So, keeping the in-kernel unused ioctl's don't bring any real benefit, as > vendors > can still do their forks, and applications designed to work with those > hardware > need to support the vendor's stack. In another thread, where I requested you to revert the audio/video ioctl removal patch, I did chime in that those headers are in use. If you consider a driver that's to be merged as an out-of tree driver, then you are asking people to go away. -- 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: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.
Em 24-11-2011 16:07, Andreas Oberritter escreveu: > On 24.11.2011 18:58, Mauro Carvalho Chehab wrote: >> Em 24-11-2011 15:51, Andreas Oberritter escreveu: >>> On 24.11.2011 18:44, Hans Verkuil wrote: On Thursday, November 24, 2011 18:08:05 Andreas Oberritter wrote: > Don't break existing Userspace APIs for no reason! It's OK to add the > new API, but - pretty please - don't just blindly remove audio.h and > video.h. They are in use since many years by av7110, out-of-tree drivers > *and more importantly* by applications. Yes, I know, you'd like to see > those out-of-tree drivers merged, but it isn't possible for many > reasons. And even if they were merged, you'd say "Port them and your > apps to V4L". No! That's not an option. I'm not breaking anything. All apps will still work. One option (and it depends on whether people like it or not) is to have audio.h, video.h and osd.h just include av7110.h and add a #warning that these headers need to be replaced by the new av7110.h. And really remove them at some point in the future. But the important thing to realize is that the ABI hasn't changed (unless I made a mistake somewhere). >>> >>> So why don't you just leave the headers where they are and add a notice >>> about the new V4L API as a comment? >>> >>> What you proposed breaks compilation. If you add a warning, it breaks >>> compilation for programs compiled with -Werror. Both are regressions. >> >> I don't mind doing it for 3.3 kernel, and add a note at >> Documentation/feature-removal-schedule.txt that the >> headers will go away on 3.4. This should give distributions >> and app developers enough time to prevent build failures, and >> prepare for the upcoming changes. > > Are you serious? > > Breaking things that worked well for many years - for an artificially > invented reason - is so annoying, I can't even find the words to express > how much this sucks. Andreas, All the in-kernel API's are there to support in-kernel drivers. Out of tree drivers can do whatever they want. As you likely know, several STB vendors have their own API's. Some use some variants of DVBv3 or DVBv5, and some use their own proprietary API's, that are even incompatible with DVB (and some even provide both). Even the ones that use DVBv3 (or v5) have their own implementation that diverges from the upstream one. Provided that such vendors don't violate the Kernel GPLv2 license where it applies, they're free do do whatever they want, forking the DVB API, or creating their own stacks. So, keeping the in-kernel unused ioctl's don't bring any real benefit, as vendors can still do their forks, and applications designed to work with those hardware need to support the vendor's stack. On the other hand, keeping an outdated API that doesn't fit well for the vendors that want to upstream their STB drivers is bad, as it creates confusion for them, and prevents innovation, as they may try to workaround on the limitation of an API designed for the first generation DVB standards. That's what Hans patches are addressing. If you have a better approach, feel free to suggest it, provided that, at the end, the API that aren't used by non-legacy drivers are removed (or moved to driver's specific ioctl's). Regards, 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 RESEND] davinci: dm646x: move vpif related code to driver core header from platform
Hi Mauro, On Thu, Nov 24, 2011 at 23:35:24, Mauro Carvalho Chehab wrote: > Em 12-11-2011 13:06, Manjunath Hadli escreveu: > > move vpif related code for capture and display drivers > > from dm646x platform header file to vpif_types.h as these definitions > > are related to driver code more than the platform or board. > > > > Signed-off-by: Manjunath Hadli > > Manju, > > Why are you re-sending a patch? > > My understanding is that you're maintaining the davinci patches, so it is > up to you to put those patches on your tree and send me a pull request when > they're done. So, please, don't pollute the ML re-sending emails that > are for yourself to handle. Since this particular patch touches arch/arm/mach-davinci as well as drivers/media/video, the plan was to queue the patch through ARM tree with your Ack. We did not get your ack the last time around[1] so it was resent. Do let me know if your ack is not needed. Thanks, Sekhar [1] http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg21840.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: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.
On Thu, Nov 24, 2011 at 11:38 PM, Mauro Carvalho Chehab wrote: > Em 24-11-2011 16:01, Manu Abraham escreveu: >> On Thu, Nov 24, 2011 at 11:14 PM, Hans Verkuil wrote: >>> On Thursday, November 24, 2011 18:08:05 Andreas Oberritter wrote: Don't break existing Userspace APIs for no reason! It's OK to add the new API, but - pretty please - don't just blindly remove audio.h and video.h. They are in use since many years by av7110, out-of-tree drivers *and more importantly* by applications. Yes, I know, you'd like to see those out-of-tree drivers merged, but it isn't possible for many reasons. And even if they were merged, you'd say "Port them and your apps to V4L". No! That's not an option. >>> >>> I'm not breaking anything. All apps will still work. >>> >>> One option (and it depends on whether people like it or not) is to have >>> audio.h, video.h and osd.h just include av7110.h and add a #warning >>> that these headers need to be replaced by the new av7110.h. >> >> >> That won't work with other non av7110 hardware. > > There isn't any non-av7110 driver using it at the Kernel. Anyway, we can put > a warning at the existing headers as-is, for now, putting them to be removed > for a new kernel version, like 3.4. No, that's not an option. The to-be merged saa716x driver depends on it. A DVB alone device need not depend V4L2 for it's operation. Also, it doesn't make any sense to have device specific headers to be used by an application, when drivers share more than one commonality. -- 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: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.
Em 24-11-2011 16:01, Manu Abraham escreveu: > On Thu, Nov 24, 2011 at 11:14 PM, Hans Verkuil wrote: >> On Thursday, November 24, 2011 18:08:05 Andreas Oberritter wrote: >>> Don't break existing Userspace APIs for no reason! It's OK to add the >>> new API, but - pretty please - don't just blindly remove audio.h and >>> video.h. They are in use since many years by av7110, out-of-tree drivers >>> *and more importantly* by applications. Yes, I know, you'd like to see >>> those out-of-tree drivers merged, but it isn't possible for many >>> reasons. And even if they were merged, you'd say "Port them and your >>> apps to V4L". No! That's not an option. >> >> I'm not breaking anything. All apps will still work. >> >> One option (and it depends on whether people like it or not) is to have >> audio.h, video.h and osd.h just include av7110.h and add a #warning >> that these headers need to be replaced by the new av7110.h. > > > That won't work with other non av7110 hardware. There isn't any non-av7110 driver using it at the Kernel. Anyway, we can put a warning at the existing headers as-is, for now, putting them to be removed for a new kernel version, like 3.4. Regards, 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: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.
On 24.11.2011 18:58, Mauro Carvalho Chehab wrote: > Em 24-11-2011 15:51, Andreas Oberritter escreveu: >> On 24.11.2011 18:44, Hans Verkuil wrote: >>> On Thursday, November 24, 2011 18:08:05 Andreas Oberritter wrote: Don't break existing Userspace APIs for no reason! It's OK to add the new API, but - pretty please - don't just blindly remove audio.h and video.h. They are in use since many years by av7110, out-of-tree drivers *and more importantly* by applications. Yes, I know, you'd like to see those out-of-tree drivers merged, but it isn't possible for many reasons. And even if they were merged, you'd say "Port them and your apps to V4L". No! That's not an option. >>> >>> I'm not breaking anything. All apps will still work. >>> >>> One option (and it depends on whether people like it or not) is to have >>> audio.h, video.h and osd.h just include av7110.h and add a #warning >>> that these headers need to be replaced by the new av7110.h. >>> >>> And really remove them at some point in the future. >>> >>> But the important thing to realize is that the ABI hasn't changed (unless >>> I made a mistake somewhere). >> >> So why don't you just leave the headers where they are and add a notice >> about the new V4L API as a comment? >> >> What you proposed breaks compilation. If you add a warning, it breaks >> compilation for programs compiled with -Werror. Both are regressions. > > I don't mind doing it for 3.3 kernel, and add a note at > Documentation/feature-removal-schedule.txt that the > headers will go away on 3.4. This should give distributions > and app developers enough time to prevent build failures, and > prepare for the upcoming changes. Are you serious? Breaking things that worked well for many years - for an artificially invented reason - is so annoying, I can't even find the words to express how much this sucks. -- 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 RESEND] davinci: dm646x: move vpif related code to driver core header from platform
Em 12-11-2011 13:06, Manjunath Hadli escreveu: > move vpif related code for capture and display drivers > from dm646x platform header file to vpif_types.h as these definitions > are related to driver code more than the platform or board. > > Signed-off-by: Manjunath Hadli Manju, Why are you re-sending a patch? My understanding is that you're maintaining the davinci patches, so it is up to you to put those patches on your tree and send me a pull request when they're done. So, please, don't pollute the ML re-sending emails that are for yourself to handle. Regards, 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: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.
On Thu, Nov 24, 2011 at 11:14 PM, Hans Verkuil wrote: > On Thursday, November 24, 2011 18:08:05 Andreas Oberritter wrote: >> Don't break existing Userspace APIs for no reason! It's OK to add the >> new API, but - pretty please - don't just blindly remove audio.h and >> video.h. They are in use since many years by av7110, out-of-tree drivers >> *and more importantly* by applications. Yes, I know, you'd like to see >> those out-of-tree drivers merged, but it isn't possible for many >> reasons. And even if they were merged, you'd say "Port them and your >> apps to V4L". No! That's not an option. > > I'm not breaking anything. All apps will still work. > > One option (and it depends on whether people like it or not) is to have > audio.h, video.h and osd.h just include av7110.h and add a #warning > that these headers need to be replaced by the new av7110.h. That won't work with other non av7110 hardware. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.
On 24.11.2011 18:37, Mauro Carvalho Chehab wrote: > Em 24-11-2011 15:08, Andreas Oberritter escreveu: >> Don't break existing Userspace APIs for no reason! It's OK to add the >> new API, but - pretty please - don't just blindly remove audio.h and >> video.h. They are in use since many years by av7110, out-of-tree drivers >> *and more importantly* by applications. Yes, I know, you'd like to see >> those out-of-tree drivers merged, but it isn't possible for many >> reasons. And even if they were merged, you'd say "Port them and your >> apps to V4L". No! That's not an option. > > Hi Andreas, > > Userspace applications that support av7110 can include the new linux/av7110.h > header. Other applications that support out-of-tree drivers can just have > their own copy of audio.h, osd.h and video.h. So, it won't break or prevent > existing applications to keep working. As already replied to Hans, breaking compilation on purpose is bad. > The thing is that the media API presents two interfaces to control mpeg > decoders. > This is confusing, and, while one of them has active upstream developers > working > on it, adding new drivers and new features on it, the other API is not being > updated accordingly, and no new upstream drivers use it. There is no "media API". There's a V4L API and a DVB API. There are active downstream developers adding new drivers and features to it. > Worse than that, several ioctl's are there, with not a single in-kernel > implementation, > nor any documentation about how they are supposed to work. I think I know how most of them are supposed to work. If you have questions, just ask. Yes, there are many ioctls which have never been used (mostly for DVD playback, IIRC). You can mark them as deprecated. > We noticed in Prague that new DVB developers got confused about what should > be the > proper implementation for new drivers, so marking it as deprecated is > important, > otherwise, we'll end by having different approaches for the same thing. There's a huge difference between marking something as deprecated and deleting userspace header files (and compat-ioctl for that matter). Adding a comment on top of audio.h and video.h will be good enough for new DVB developers. > Just to give you one example, newer DTV standards like ISDB-T and DVB-T2 now > uses > H.264 video streams. Support for H.264 were added recently at V4L2 API, but > the > dvb video API doesn't support it. My attempts to add the necessary #defines for new video standards were blocked because there was no in-kernel driver available. You can't use that as an argument against it now. If you like, I can submit patches to address this. Regards, Andreas -- 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: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.
On Thu, Nov 24, 2011 at 11:07 PM, Mauro Carvalho Chehab wrote: > Em 24-11-2011 15:08, Andreas Oberritter escreveu: >> Don't break existing Userspace APIs for no reason! It's OK to add the >> new API, but - pretty please - don't just blindly remove audio.h and >> video.h. They are in use since many years by av7110, out-of-tree drivers >> *and more importantly* by applications. Yes, I know, you'd like to see >> those out-of-tree drivers merged, but it isn't possible for many >> reasons. And even if they were merged, you'd say "Port them and your >> apps to V4L". No! That's not an option. > > Hi Andreas, > > Userspace applications that support av7110 can include the new linux/av7110.h > header. Other applications that support out-of-tree drivers can just have > their own copy of audio.h, osd.h and video.h. So, it won't break or prevent > existing applications to keep working. > > The thing is that the media API presents two interfaces to control mpeg > decoders. > This is confusing, and, while one of them has active upstream developers > working > on it, adding new drivers and new features on it, the other API is not being > updated accordingly, and no new upstream drivers use it. > > Worse than that, several ioctl's are there, with not a single in-kernel > implementation, > nor any documentation about how they are supposed to work. > > We noticed in Prague that new DVB developers got confused about what should > be the > proper implementation for new drivers, so marking it as deprecated is > important, > otherwise, we'll end by having different approaches for the same thing. > > Just to give you one example, newer DTV standards like ISDB-T and DVB-T2 now > uses > H.264 video streams. Support for H.264 were added recently at V4L2 API, but > the > dvb video API doesn't support it. That's not true at all. I am testing DVB-S2/H.264 with the current DVB API. -- 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: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.
Em 24-11-2011 15:51, Andreas Oberritter escreveu: > On 24.11.2011 18:44, Hans Verkuil wrote: >> On Thursday, November 24, 2011 18:08:05 Andreas Oberritter wrote: >>> Don't break existing Userspace APIs for no reason! It's OK to add the >>> new API, but - pretty please - don't just blindly remove audio.h and >>> video.h. They are in use since many years by av7110, out-of-tree drivers >>> *and more importantly* by applications. Yes, I know, you'd like to see >>> those out-of-tree drivers merged, but it isn't possible for many >>> reasons. And even if they were merged, you'd say "Port them and your >>> apps to V4L". No! That's not an option. >> >> I'm not breaking anything. All apps will still work. >> >> One option (and it depends on whether people like it or not) is to have >> audio.h, video.h and osd.h just include av7110.h and add a #warning >> that these headers need to be replaced by the new av7110.h. >> >> And really remove them at some point in the future. >> >> But the important thing to realize is that the ABI hasn't changed (unless >> I made a mistake somewhere). > > So why don't you just leave the headers where they are and add a notice > about the new V4L API as a comment? > > What you proposed breaks compilation. If you add a warning, it breaks > compilation for programs compiled with -Werror. Both are regressions. I don't mind doing it for 3.3 kernel, and add a note at Documentation/feature-removal-schedule.txt that the headers will go away on 3.4. This should give distributions and app developers enough time to prevent build failures, and prepare for the upcoming changes. Regards, Mauro. > > Regards, > Andreas > -- > 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: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.
On 24.11.2011 18:44, Hans Verkuil wrote: > On Thursday, November 24, 2011 18:08:05 Andreas Oberritter wrote: >> Don't break existing Userspace APIs for no reason! It's OK to add the >> new API, but - pretty please - don't just blindly remove audio.h and >> video.h. They are in use since many years by av7110, out-of-tree drivers >> *and more importantly* by applications. Yes, I know, you'd like to see >> those out-of-tree drivers merged, but it isn't possible for many >> reasons. And even if they were merged, you'd say "Port them and your >> apps to V4L". No! That's not an option. > > I'm not breaking anything. All apps will still work. > > One option (and it depends on whether people like it or not) is to have > audio.h, video.h and osd.h just include av7110.h and add a #warning > that these headers need to be replaced by the new av7110.h. > > And really remove them at some point in the future. > > But the important thing to realize is that the ABI hasn't changed (unless > I made a mistake somewhere). So why don't you just leave the headers where they are and add a notice about the new V4L API as a comment? What you proposed breaks compilation. If you add a warning, it breaks compilation for programs compiled with -Werror. Both are regressions. Regards, Andreas -- 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: ir-sanyo-decoder.c doesn't compile
Em 24-11-2011 10:47, Hans Verkuil escreveu: > I get this error when compiling for_v3.3: > > drivers/media/rc/ir-sanyo-decoder.c:201:16: error: expected declaration > specifiers or ‘...’ before string constant > drivers/media/rc/ir-sanyo-decoder.c:202:15: error: expected declaration > specifiers or ‘...’ before string constant > drivers/media/rc/ir-sanyo-decoder.c:203:15: error: expected declaration > specifiers or ‘...’ before string constant > drivers/media/rc/ir-sanyo-decoder.c:204:20: error: expected declaration > specifiers or ‘...’ before string constant > > There is a include missing. > > This patch fixes this: Thanks for noticing it. It is likely due to the merge from 3.3-rc2. Anyway, applied. > > diff --git a/drivers/media/rc/ir-sanyo-decoder.c > b/drivers/media/rc/ir-sanyo-decoder.c > index 1646730..d38fbdd 100644 > --- a/drivers/media/rc/ir-sanyo-decoder.c > +++ b/drivers/media/rc/ir-sanyo-decoder.c > @@ -21,6 +21,7 @@ > * Information for this protocol is available at the Sanyo LC7461 datasheet. > */ > > +#include > #include > #include "rc-core-priv.h" > > Signed-off-by: Hans Verkuil > > 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: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.
On Thursday, November 24, 2011 18:08:05 Andreas Oberritter wrote:
> Don't break existing Userspace APIs for no reason! It's OK to add the
> new API, but - pretty please - don't just blindly remove audio.h and
> video.h. They are in use since many years by av7110, out-of-tree drivers
> *and more importantly* by applications. Yes, I know, you'd like to see
> those out-of-tree drivers merged, but it isn't possible for many
> reasons. And even if they were merged, you'd say "Port them and your
> apps to V4L". No! That's not an option.
I'm not breaking anything. All apps will still work.
One option (and it depends on whether people like it or not) is to have
audio.h, video.h and osd.h just include av7110.h and add a #warning
that these headers need to be replaced by the new av7110.h.
And really remove them at some point in the future.
But the important thing to realize is that the ABI hasn't changed (unless
I made a mistake somewhere).
Regards,
Hans
>
> Regards,
> Andreas
>
> On 24.11.2011 14:39, Hans Verkuil wrote:
> > From: Hans Verkuil
> >
> > Signed-off-by: Hans Verkuil
> > ---
> > fs/compat_ioctl.c | 41 +---
> > include/linux/dvb/Kbuild |3 -
> > include/linux/dvb/audio.h | 135 --
> > include/linux/dvb/osd.h | 144 ---
> > include/linux/dvb/video.h | 276
> > -
> > 5 files changed, 1 insertions(+), 598 deletions(-)
> > delete mode 100644 include/linux/dvb/audio.h
> > delete mode 100644 include/linux/dvb/osd.h
> > delete mode 100644 include/linux/dvb/video.h
> >
> > diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
> > index 51352de..71adea1 100644
> > --- a/fs/compat_ioctl.c
> > +++ b/fs/compat_ioctl.c
> > @@ -105,10 +105,9 @@
> >
> > #include
> >
> > -#include
> > +#include
> > #include
> > #include
> > -#include
> >
> > #include
> >
> > @@ -196,32 +195,6 @@ static int do_video_stillpicture(unsigned int fd,
> > unsigned int cmd,
> > return err;
> > }
> >
> > -struct compat_video_spu_palette {
> > - int length;
> > - compat_uptr_t palette;
> > -};
> > -
> > -static int do_video_set_spu_palette(unsigned int fd, unsigned int cmd,
> > - struct compat_video_spu_palette __user *up)
> > -{
> > - struct video_spu_palette __user *up_native;
> > - compat_uptr_t palp;
> > - int length, err;
> > -
> > - err = get_user(palp, &up->palette);
> > - err |= get_user(length, &up->length);
> > -
> > - up_native = compat_alloc_user_space(sizeof(struct video_spu_palette));
> > - err = put_user(compat_ptr(palp), &up_native->palette);
> > - err |= put_user(length, &up_native->length);
> > - if (err)
> > - return -EFAULT;
> > -
> > - err = sys_ioctl(fd, cmd, (unsigned long) up_native);
> > -
> > - return err;
> > -}
> > -
> > #ifdef CONFIG_BLOCK
> > typedef struct sg_io_hdr32 {
> > compat_int_t interface_id; /* [i] 'S' for SCSI generic (required)
> > */
> > @@ -1317,9 +1290,6 @@ COMPATIBLE_IOCTL(AUDIO_CLEAR_BUFFER)
> > COMPATIBLE_IOCTL(AUDIO_SET_ID)
> > COMPATIBLE_IOCTL(AUDIO_SET_MIXER)
> > COMPATIBLE_IOCTL(AUDIO_SET_STREAMTYPE)
> > -COMPATIBLE_IOCTL(AUDIO_SET_EXT_ID)
> > -COMPATIBLE_IOCTL(AUDIO_SET_ATTRIBUTES)
> > -COMPATIBLE_IOCTL(AUDIO_SET_KARAOKE)
> > COMPATIBLE_IOCTL(DMX_START)
> > COMPATIBLE_IOCTL(DMX_STOP)
> > COMPATIBLE_IOCTL(DMX_SET_FILTER)
> > @@ -1358,16 +1328,9 @@ COMPATIBLE_IOCTL(VIDEO_FAST_FORWARD)
> > COMPATIBLE_IOCTL(VIDEO_SLOWMOTION)
> > COMPATIBLE_IOCTL(VIDEO_GET_CAPABILITIES)
> > COMPATIBLE_IOCTL(VIDEO_CLEAR_BUFFER)
> > -COMPATIBLE_IOCTL(VIDEO_SET_ID)
> > COMPATIBLE_IOCTL(VIDEO_SET_STREAMTYPE)
> > COMPATIBLE_IOCTL(VIDEO_SET_FORMAT)
> > -COMPATIBLE_IOCTL(VIDEO_SET_SYSTEM)
> > -COMPATIBLE_IOCTL(VIDEO_SET_HIGHLIGHT)
> > -COMPATIBLE_IOCTL(VIDEO_SET_SPU)
> > -COMPATIBLE_IOCTL(VIDEO_GET_NAVI)
> > -COMPATIBLE_IOCTL(VIDEO_SET_ATTRIBUTES)
> > COMPATIBLE_IOCTL(VIDEO_GET_SIZE)
> > -COMPATIBLE_IOCTL(VIDEO_GET_FRAME_RATE)
> >
> > /* joystick */
> > COMPATIBLE_IOCTL(JSIOCGVERSION)
> > @@ -1468,8 +1431,6 @@ static long do_ioctl_trans(int fd, unsigned int cmd,
> > return do_video_get_event(fd, cmd, argp);
> > case VIDEO_STILLPICTURE:
> > return do_video_stillpicture(fd, cmd, argp);
> > - case VIDEO_SET_SPU_PALETTE:
> > - return do_video_set_spu_palette(fd, cmd, argp);
> > }
> >
> > /*
> > diff --git a/include/linux/dvb/Kbuild b/include/linux/dvb/Kbuild
> > index f4dba86..f5aa137 100644
> > --- a/include/linux/dvb/Kbuild
> > +++ b/include/linux/dvb/Kbuild
> > @@ -1,8 +1,5 @@
> > -header-y += audio.h
> > header-y += ca.h
> > header-y += dmx.h
> > header-y += frontend.h
> > header-y += net.h
> > -header-y += osd.h
> > header-y += version.h
> > -header-y += video.h
> > diff --git a/include/linux/dvb/audio.h b/include/linux/dvb/audio.h
> > deleted file mode 100644
> > index d47bccd..000
> > --- a/include/linux/dvb/audio.h
> > +++ /dev/nul
Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.
Em 24-11-2011 15:08, Andreas Oberritter escreveu:
> Don't break existing Userspace APIs for no reason! It's OK to add the
> new API, but - pretty please - don't just blindly remove audio.h and
> video.h. They are in use since many years by av7110, out-of-tree drivers
> *and more importantly* by applications. Yes, I know, you'd like to see
> those out-of-tree drivers merged, but it isn't possible for many
> reasons. And even if they were merged, you'd say "Port them and your
> apps to V4L". No! That's not an option.
Hi Andreas,
Userspace applications that support av7110 can include the new linux/av7110.h
header. Other applications that support out-of-tree drivers can just have
their own copy of audio.h, osd.h and video.h. So, it won't break or prevent
existing applications to keep working.
The thing is that the media API presents two interfaces to control mpeg
decoders.
This is confusing, and, while one of them has active upstream developers working
on it, adding new drivers and new features on it, the other API is not being
updated accordingly, and no new upstream drivers use it.
Worse than that, several ioctl's are there, with not a single in-kernel
implementation,
nor any documentation about how they are supposed to work.
We noticed in Prague that new DVB developers got confused about what should be
the
proper implementation for new drivers, so marking it as deprecated is important,
otherwise, we'll end by having different approaches for the same thing.
Just to give you one example, newer DTV standards like ISDB-T and DVB-T2 now
uses
H.264 video streams. Support for H.264 were added recently at V4L2 API, but the
dvb video API doesn't support it.
What I'm saying is that this API is legacy, from kernel POV. So, let's freeze
it to DVB v5.4
spec, and remove it from the official Kernel DVB API on future versions (yet,
keeping it
as a private API for av7110). It probably makes sense to increase the major
version
at DVB API, when this patches got merged, to indicate that DVB v6 and above
doesn't
have it anymore, while v5.4 and bellow has it.
>
> Regards,
> Andreas
>
> On 24.11.2011 14:39, Hans Verkuil wrote:
>> From: Hans Verkuil
>>
>> Signed-off-by: Hans Verkuil
>> ---
>> fs/compat_ioctl.c | 41 +---
>> include/linux/dvb/Kbuild |3 -
>> include/linux/dvb/audio.h | 135 --
>> include/linux/dvb/osd.h | 144 ---
>> include/linux/dvb/video.h | 276
>> -
>> 5 files changed, 1 insertions(+), 598 deletions(-)
>> delete mode 100644 include/linux/dvb/audio.h
>> delete mode 100644 include/linux/dvb/osd.h
>> delete mode 100644 include/linux/dvb/video.h
>>
>> diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
>> index 51352de..71adea1 100644
>> --- a/fs/compat_ioctl.c
>> +++ b/fs/compat_ioctl.c
>> @@ -105,10 +105,9 @@
>>
>> #include
>>
>> -#include
>> +#include
>> #include
>> #include
>> -#include
>>
>> #include
>>
>> @@ -196,32 +195,6 @@ static int do_video_stillpicture(unsigned int fd,
>> unsigned int cmd,
>> return err;
>> }
>>
>> -struct compat_video_spu_palette {
>> -int length;
>> -compat_uptr_t palette;
>> -};
>> -
>> -static int do_video_set_spu_palette(unsigned int fd, unsigned int cmd,
>> -struct compat_video_spu_palette __user *up)
>> -{
>> -struct video_spu_palette __user *up_native;
>> -compat_uptr_t palp;
>> -int length, err;
>> -
>> -err = get_user(palp, &up->palette);
>> -err |= get_user(length, &up->length);
>> -
>> -up_native = compat_alloc_user_space(sizeof(struct video_spu_palette));
>> -err = put_user(compat_ptr(palp), &up_native->palette);
>> -err |= put_user(length, &up_native->length);
>> -if (err)
>> -return -EFAULT;
>> -
>> -err = sys_ioctl(fd, cmd, (unsigned long) up_native);
>> -
>> -return err;
>> -}
>> -
>> #ifdef CONFIG_BLOCK
>> typedef struct sg_io_hdr32 {
>> compat_int_t interface_id; /* [i] 'S' for SCSI generic (required)
>> */
>> @@ -1317,9 +1290,6 @@ COMPATIBLE_IOCTL(AUDIO_CLEAR_BUFFER)
>> COMPATIBLE_IOCTL(AUDIO_SET_ID)
>> COMPATIBLE_IOCTL(AUDIO_SET_MIXER)
>> COMPATIBLE_IOCTL(AUDIO_SET_STREAMTYPE)
>> -COMPATIBLE_IOCTL(AUDIO_SET_EXT_ID)
>> -COMPATIBLE_IOCTL(AUDIO_SET_ATTRIBUTES)
>> -COMPATIBLE_IOCTL(AUDIO_SET_KARAOKE)
>> COMPATIBLE_IOCTL(DMX_START)
>> COMPATIBLE_IOCTL(DMX_STOP)
>> COMPATIBLE_IOCTL(DMX_SET_FILTER)
>> @@ -1358,16 +1328,9 @@ COMPATIBLE_IOCTL(VIDEO_FAST_FORWARD)
>> COMPATIBLE_IOCTL(VIDEO_SLOWMOTION)
>> COMPATIBLE_IOCTL(VIDEO_GET_CAPABILITIES)
>> COMPATIBLE_IOCTL(VIDEO_CLEAR_BUFFER)
>> -COMPATIBLE_IOCTL(VIDEO_SET_ID)
>> COMPATIBLE_IOCTL(VIDEO_SET_STREAMTYPE)
>> COMPATIBLE_IOCTL(VIDEO_SET_FORMAT)
>> -COMPATIBLE_IOCTL(VIDEO_SET_SYSTEM)
>> -COMPATIBLE_IOCTL(VIDEO_SET_HIGHLIGHT)
>> -COMPATIBLE_IOCTL(VIDEO_SET_SPU)
>> -COMPATIBLE_IOCTL(VIDEO_GET_NAVI)
>> -COMPATIBLE_IOCTL(VIDEO_SET_ATTRIBUTES)
>> COMPATIBLE_IOCTL(VIDEO_
Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.
Don't break existing Userspace APIs for no reason! It's OK to add the
new API, but - pretty please - don't just blindly remove audio.h and
video.h. They are in use since many years by av7110, out-of-tree drivers
*and more importantly* by applications. Yes, I know, you'd like to see
those out-of-tree drivers merged, but it isn't possible for many
reasons. And even if they were merged, you'd say "Port them and your
apps to V4L". No! That's not an option.
Regards,
Andreas
On 24.11.2011 14:39, Hans Verkuil wrote:
> From: Hans Verkuil
>
> Signed-off-by: Hans Verkuil
> ---
> fs/compat_ioctl.c | 41 +---
> include/linux/dvb/Kbuild |3 -
> include/linux/dvb/audio.h | 135 --
> include/linux/dvb/osd.h | 144 ---
> include/linux/dvb/video.h | 276
> -
> 5 files changed, 1 insertions(+), 598 deletions(-)
> delete mode 100644 include/linux/dvb/audio.h
> delete mode 100644 include/linux/dvb/osd.h
> delete mode 100644 include/linux/dvb/video.h
>
> diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
> index 51352de..71adea1 100644
> --- a/fs/compat_ioctl.c
> +++ b/fs/compat_ioctl.c
> @@ -105,10 +105,9 @@
>
> #include
>
> -#include
> +#include
> #include
> #include
> -#include
>
> #include
>
> @@ -196,32 +195,6 @@ static int do_video_stillpicture(unsigned int fd,
> unsigned int cmd,
> return err;
> }
>
> -struct compat_video_spu_palette {
> - int length;
> - compat_uptr_t palette;
> -};
> -
> -static int do_video_set_spu_palette(unsigned int fd, unsigned int cmd,
> - struct compat_video_spu_palette __user *up)
> -{
> - struct video_spu_palette __user *up_native;
> - compat_uptr_t palp;
> - int length, err;
> -
> - err = get_user(palp, &up->palette);
> - err |= get_user(length, &up->length);
> -
> - up_native = compat_alloc_user_space(sizeof(struct video_spu_palette));
> - err = put_user(compat_ptr(palp), &up_native->palette);
> - err |= put_user(length, &up_native->length);
> - if (err)
> - return -EFAULT;
> -
> - err = sys_ioctl(fd, cmd, (unsigned long) up_native);
> -
> - return err;
> -}
> -
> #ifdef CONFIG_BLOCK
> typedef struct sg_io_hdr32 {
> compat_int_t interface_id; /* [i] 'S' for SCSI generic (required)
> */
> @@ -1317,9 +1290,6 @@ COMPATIBLE_IOCTL(AUDIO_CLEAR_BUFFER)
> COMPATIBLE_IOCTL(AUDIO_SET_ID)
> COMPATIBLE_IOCTL(AUDIO_SET_MIXER)
> COMPATIBLE_IOCTL(AUDIO_SET_STREAMTYPE)
> -COMPATIBLE_IOCTL(AUDIO_SET_EXT_ID)
> -COMPATIBLE_IOCTL(AUDIO_SET_ATTRIBUTES)
> -COMPATIBLE_IOCTL(AUDIO_SET_KARAOKE)
> COMPATIBLE_IOCTL(DMX_START)
> COMPATIBLE_IOCTL(DMX_STOP)
> COMPATIBLE_IOCTL(DMX_SET_FILTER)
> @@ -1358,16 +1328,9 @@ COMPATIBLE_IOCTL(VIDEO_FAST_FORWARD)
> COMPATIBLE_IOCTL(VIDEO_SLOWMOTION)
> COMPATIBLE_IOCTL(VIDEO_GET_CAPABILITIES)
> COMPATIBLE_IOCTL(VIDEO_CLEAR_BUFFER)
> -COMPATIBLE_IOCTL(VIDEO_SET_ID)
> COMPATIBLE_IOCTL(VIDEO_SET_STREAMTYPE)
> COMPATIBLE_IOCTL(VIDEO_SET_FORMAT)
> -COMPATIBLE_IOCTL(VIDEO_SET_SYSTEM)
> -COMPATIBLE_IOCTL(VIDEO_SET_HIGHLIGHT)
> -COMPATIBLE_IOCTL(VIDEO_SET_SPU)
> -COMPATIBLE_IOCTL(VIDEO_GET_NAVI)
> -COMPATIBLE_IOCTL(VIDEO_SET_ATTRIBUTES)
> COMPATIBLE_IOCTL(VIDEO_GET_SIZE)
> -COMPATIBLE_IOCTL(VIDEO_GET_FRAME_RATE)
>
> /* joystick */
> COMPATIBLE_IOCTL(JSIOCGVERSION)
> @@ -1468,8 +1431,6 @@ static long do_ioctl_trans(int fd, unsigned int cmd,
> return do_video_get_event(fd, cmd, argp);
> case VIDEO_STILLPICTURE:
> return do_video_stillpicture(fd, cmd, argp);
> - case VIDEO_SET_SPU_PALETTE:
> - return do_video_set_spu_palette(fd, cmd, argp);
> }
>
> /*
> diff --git a/include/linux/dvb/Kbuild b/include/linux/dvb/Kbuild
> index f4dba86..f5aa137 100644
> --- a/include/linux/dvb/Kbuild
> +++ b/include/linux/dvb/Kbuild
> @@ -1,8 +1,5 @@
> -header-y += audio.h
> header-y += ca.h
> header-y += dmx.h
> header-y += frontend.h
> header-y += net.h
> -header-y += osd.h
> header-y += version.h
> -header-y += video.h
> diff --git a/include/linux/dvb/audio.h b/include/linux/dvb/audio.h
> deleted file mode 100644
> index d47bccd..000
> --- a/include/linux/dvb/audio.h
> +++ /dev/null
> @@ -1,135 +0,0 @@
> -/*
> - * audio.h
> - *
> - * Copyright (C) 2000 Ralph Metzler
> - * & Marcus Metzler
> - *for convergence integrated media GmbH
> - *
> - * This program is free software; you can redistribute it and/or
> - * modify it under the terms of the GNU General Lesser Public License
> - * as published by the Free Software Foundation; either version 2.1
> - * of the License, or (at your option) any later version.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> - * GNU General Public License f
[PATCH 2/2] [media] firedtv-avc: Fix compilation warnings
drivers/media/dvb/firewire/firedtv-avc.c: In function ‘avc_tuner_tuneqpsk’:
drivers/media/dvb/firewire/firedtv-avc.c:394:4: warning: enumeration value
‘ROLLOFF_15’ not handled in switch [-Wswitch]
drivers/media/dvb/firewire/firedtv-avc.c:394:4: warning: enumeration value
‘ROLLOFF_13’ not handled in switch [-Wswitch]
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/dvb/firewire/firedtv-avc.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/media/dvb/firewire/firedtv-avc.c
b/drivers/media/dvb/firewire/firedtv-avc.c
index 489ae82..9debf0f 100644
--- a/drivers/media/dvb/firewire/firedtv-avc.c
+++ b/drivers/media/dvb/firewire/firedtv-avc.c
@@ -392,10 +392,11 @@ static int avc_tuner_tuneqpsk(struct firedtv *fdtv,
default:c->operand[13] = 0x2; break;
}
switch (fdtv->fe.dtv_property_cache.rolloff) {
- case ROLLOFF_AUTO: c->operand[14] = 0x2; break;
case ROLLOFF_35:c->operand[14] = 0x2; break;
case ROLLOFF_20:c->operand[14] = 0x0; break;
case ROLLOFF_25:c->operand[14] = 0x1; break;
+ case ROLLOFF_AUTO:
+ default:c->operand[14] = 0x2; break;
/* case ROLLOFF_NONE: c->operand[14] = 0xff; break; */
}
switch (fdtv->fe.dtv_property_cache.pilot) {
--
1.7.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] [media] em28xx: Fix a few warnings due to HVR-930C addition
drivers/media/video/em28xx/em28xx-cards.c:339:30: warning:
‘hauppauge_930c_gpio’ defined but not used [-Wunused-variable]
drivers/media/video/em28xx/em28xx-dvb.c: In function ‘em28xx_dvb_init’:
drivers/media/video/em28xx/em28xx-dvb.c:886:3: warning: ISO C90 forbids mixed
declarations and code [-Wdeclaration-after-statement]
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/video/em28xx/em28xx-cards.c |2 +-
drivers/media/video/em28xx/em28xx-dvb.c |4 +++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/em28xx/em28xx-cards.c
b/drivers/media/video/em28xx/em28xx-cards.c
index f63a715..5b0336b 100644
--- a/drivers/media/video/em28xx/em28xx-cards.c
+++ b/drivers/media/video/em28xx/em28xx-cards.c
@@ -336,6 +336,7 @@ static struct em28xx_reg_seq pctv_460e[] = {
{ -1, -1, -1, -1},
};
+#if 0
static struct em28xx_reg_seq hauppauge_930c_gpio[] = {
{EM2874_R80_GPIO, 0x6f, 0xff, 10},
{EM2874_R80_GPIO, 0x4f, 0xff, 10}, /* xc5000 reset */
@@ -344,7 +345,6 @@ static struct em28xx_reg_seq hauppauge_930c_gpio[] = {
{ -1, -1, -1, -1},
};
-#if 0
static struct em28xx_reg_seq hauppauge_930c_digital[] = {
{EM2874_R80_GPIO, 0xf6, 0xff, 10},
{EM2874_R80_GPIO, 0xe6, 0xff, 100},
diff --git a/drivers/media/video/em28xx/em28xx-dvb.c
b/drivers/media/video/em28xx/em28xx-dvb.c
index 55a9008..ea2208e 100644
--- a/drivers/media/video/em28xx/em28xx-dvb.c
+++ b/drivers/media/video/em28xx/em28xx-dvb.c
@@ -864,6 +864,8 @@ static int em28xx_dvb_init(struct em28xx *dev)
}
break;
case EM2884_BOARD_HAUPPAUGE_WINTV_HVR_930C:
+ {
+ struct xc5000_config cfg;
hauppauge_hvr930c_init(dev);
dvb->dont_attach_fe1 = 1;
@@ -883,7 +885,6 @@ static int em28xx_dvb_init(struct em28xx *dev)
dvb->fe[1]->id = 1;
/* Attach xc5000 */
- struct xc5000_config cfg;
memset(&cfg, 0, sizeof(cfg));
cfg.i2c_address = 0x61;
cfg.if_khz = 4000;
@@ -906,6 +907,7 @@ static int em28xx_dvb_init(struct em28xx *dev)
sizeof(dvb->fe[0]->ops.tuner_ops));
break;
+ }
case EM2884_BOARD_TERRATEC_H5:
terratec_h5_init(dev);
--
1.7.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Revert most of 15cc2bb [media] DVB: dtv_property_cache_submit shouldn't modifiy the cache
Em 05-11-2011 15:57, Lawrence Rust escreveu: > On Sat, 2011-11-05 at 18:38 +0100, Andreas Oberritter wrote: > [snip] >> I don't get how this could be useful. MythTV knows what delivery system >> it wants to use, so it should pass this information to the kernel. >> Trying to set an invalid delivery system must fail. >> >> Using SYS_UNDEFINED as a pre-set default is different from setting >> SYS_UNDEFINED from userspace, which should always generate an error IMO, >> unless this is documented otherwise in the API specification. > > It's not ideal that MythTV is setting DTV_DELIVERY_SYSTEM to 0 and I > have filed a bug against this. But that doesn't change the fact that > the original patch significantly changed user parameter handling for no > significant benefit. MythTV is probably the biggest client of v4l and > will greatly hinder users upgrading to (Myth)Ubuntu 12.04 or Fedora 16 > both of which use Linux 3.x. Regression is a bad thing. However, in this specific case, I agree with Andreas: an assumption that the Kernel will replace SYS_UNDEFINED by something else is a very bad thing. It also hides a bug, as there are no way for devices that support more than one delivery system to properly select the desired one. So, this patch won't fix it. So, I suspect that you'll need to open a BZ also at Ubuntu and Fedora, in order to backport the MythTV fix into them. Regards, 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] Fix tm6010 audio
Em 07-11-2011 22:45, Dmitri Belimov escreveu:
> Hi
>
> I found why audio dosn't work for me and fix it.
>
> 2Stefan:
> The V4L2_STD_DK has V4L2_STD_SECAM_DK but not equal
> switch-case statement not worked
>
> you can use
> if (dev->norm & V4L2_STD_DK) {
> }
>
> This patch fix this problem.
>
> Other, please don't remove any workarounds without important reason.
> For your chip revision it can be work but for other audio will be bad.
>
> I can watch TV but radio not work. After start Gnomeradio I see
> VIDIOCGAUDIO incorrect
> VIDIOCSAUDIO incorrect
> VIDIOCSFREQ incorrect
>
> Try found what happens with radio.
This patch has several issues. The usage of switch for video doesn't work
well. A better approach follows. Not tested yet.
PS.: I couldn't test it: not sure why, but the audio source is not working
for me: arecord is not able to read from the device input.
-
[media] tm6000: Fix tm6010 audio standard selection
A V4L2 standards mask may contain several standards. A more restricted
mask with just one standard is used when user needs to bind to an specific
standard that can't be auto-detect among a more generic mask.
So, Improve the autodetection logic to detect the correct audio standard
most of the time.
Based on a patch made by Dmitri Belimov .
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/video/tm6000/tm6000-core.c
b/drivers/media/video/tm6000/tm6000-core.c
index 9783616..55d097e 100644
--- a/drivers/media/video/tm6000/tm6000-core.c
+++ b/drivers/media/video/tm6000/tm6000-core.c
@@ -696,11 +696,13 @@ int tm6000_set_audio_rinput(struct tm6000_core *dev)
if (dev->dev_type == TM6010) {
/* Audio crossbar setting, default SIF1 */
u8 areg_f0;
+ u8 areg_07 = 0x10;
switch (dev->rinput.amux) {
case TM6000_AMUX_SIF1:
case TM6000_AMUX_SIF2:
areg_f0 = 0x03;
+ areg_07 = 0x30;
break;
case TM6000_AMUX_ADC1:
areg_f0 = 0x00;
@@ -720,6 +722,9 @@ int tm6000_set_audio_rinput(struct tm6000_core *dev)
/* Set audio input crossbar */
tm6000_set_reg_mask(dev, TM6010_REQ08_RF0_DAUDIO_INPUT_CONFIG,
areg_f0, 0x0f);
+ /* Mux overflow workaround */
+ tm6000_set_reg_mask(dev, TM6010_REQ07_R07_OUTPUT_CONTROL,
+ areg_07, 0xf0);
} else {
u8 areg_eb;
/* Audio setting, default LINE1 */
diff --git a/drivers/media/video/tm6000/tm6000-stds.c
b/drivers/media/video/tm6000/tm6000-stds.c
index 9a4145d..9dc0831 100644
--- a/drivers/media/video/tm6000/tm6000-stds.c
+++ b/drivers/media/video/tm6000/tm6000-stds.c
@@ -361,82 +361,51 @@ static int tm6000_set_audio_std(struct tm6000_core *dev)
return 0;
}
- switch (tm6010_a_mode) {
+ /*
+* STD/MN shouldn't be affected by tm6010_a_mode, as there's just one
+* audio standard for each V4L2_STD type.
+*/
+ if ((dev->norm & V4L2_STD_NTSC) == V4L2_STD_NTSC_M_KR) {
+ areg_05 |= 0x04;
+ } else if ((dev->norm & V4L2_STD_NTSC) == V4L2_STD_NTSC_M_JP) {
+ areg_05 |= 0x43;
+ } else if (dev->norm & V4L2_STD_MN) {
+ areg_05 |= 0x22;
+ } else switch (tm6010_a_mode) {
/* auto */
case 0:
- switch (dev->norm) {
- case V4L2_STD_NTSC_M_KR:
+ if ((dev->norm & V4L2_STD_SECAM) == V4L2_STD_SECAM_L)
areg_05 |= 0x00;
- break;
- case V4L2_STD_NTSC_M_JP:
- areg_05 |= 0x40;
- break;
- case V4L2_STD_NTSC_M:
- case V4L2_STD_PAL_M:
- case V4L2_STD_PAL_N:
- areg_05 |= 0x20;
- break;
- case V4L2_STD_PAL_Nc:
- areg_05 |= 0x60;
- break;
- case V4L2_STD_SECAM_L:
- areg_05 |= 0x00;
- break;
- case V4L2_STD_DK:
+ else/* Other PAL/SECAM standards */
areg_05 |= 0x10;
- break;
- }
break;
/* A2 */
case 1:
- switch (dev->norm) {
- case V4L2_STD_B:
- case V4L2_STD_GH:
- areg_05 = 0x05;
- break;
- case V4L2_STD_DK:
+ if (dev->norm & V4L2_STD_DK)
areg_05 = 0x09;
- break;
- }
+ else
+ areg_05 = 0x05;
break;
/* NICAM */
case 2:
- switch (dev->norm) {
-
[RFC/PATCH 1/3] v4l: Introduce integer menu controls
Create a new control type called V4L2_CTRL_TYPE_INTEGER_MENU. Integer menu
controls are just like menu controls but the menu items are 64-bit integers
rather than strings.
Signed-off-by: Sakari Ailus
---
drivers/media/video/v4l2-ctrls.c | 63 +++--
include/linux/videodev2.h|6 +++-
include/media/v4l2-ctrls.h |6 +++-
3 files changed, 56 insertions(+), 19 deletions(-)
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 0f415da..609eb31 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -804,7 +804,8 @@ static void fill_event(struct v4l2_event *ev, struct
v4l2_ctrl *ctrl, u32 change
ev->u.ctrl.value64 = ctrl->cur.val64;
ev->u.ctrl.minimum = ctrl->minimum;
ev->u.ctrl.maximum = ctrl->maximum;
- if (ctrl->type == V4L2_CTRL_TYPE_MENU)
+ if (ctrl->type == V4L2_CTRL_TYPE_MENU
+ || ctrl->type == V4L2_CTRL_TYPE_INTEGER_MENU)
ev->u.ctrl.step = 1;
else
ev->u.ctrl.step = ctrl->step;
@@ -1035,10 +1036,13 @@ static int validate_new_int(const struct v4l2_ctrl
*ctrl, s32 *pval)
return 0;
case V4L2_CTRL_TYPE_MENU:
+ case V4L2_CTRL_TYPE_INTEGER_MENU:
if (val < ctrl->minimum || val > ctrl->maximum)
return -ERANGE;
- if (ctrl->qmenu[val][0] == '\0' ||
- (ctrl->menu_skip_mask & (1 << val)))
+ if (ctrl->menu_skip_mask & (1 << val))
+ return -EINVAL;
+ if (ctrl->type == V4L2_CTRL_TYPE_MENU &&
+ ctrl->qmenu[val][0] == '\0')
return -EINVAL;
return 0;
@@ -1295,7 +1299,8 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
v4l2_ctrl_handler *hdl,
const struct v4l2_ctrl_ops *ops,
u32 id, const char *name, enum v4l2_ctrl_type type,
s32 min, s32 max, u32 step, s32 def,
- u32 flags, const char * const *qmenu, void *priv)
+ u32 flags, const char * const *qmenu,
+ const s64 *qmenu_int, void *priv)
{
struct v4l2_ctrl *ctrl;
unsigned sz_extra = 0;
@@ -1308,6 +1313,7 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
v4l2_ctrl_handler *hdl,
(type == V4L2_CTRL_TYPE_INTEGER && step == 0) ||
(type == V4L2_CTRL_TYPE_BITMASK && max == 0) ||
(type == V4L2_CTRL_TYPE_MENU && qmenu == NULL) ||
+ (type == V4L2_CTRL_TYPE_INTEGER_MENU && qmenu_int == NULL) ||
(type == V4L2_CTRL_TYPE_STRING && max == 0)) {
handler_set_err(hdl, -ERANGE);
return NULL;
@@ -1318,6 +1324,7 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
v4l2_ctrl_handler *hdl,
}
if ((type == V4L2_CTRL_TYPE_INTEGER ||
type == V4L2_CTRL_TYPE_MENU ||
+type == V4L2_CTRL_TYPE_INTEGER_MENU ||
type == V4L2_CTRL_TYPE_BOOLEAN) &&
(def < min || def > max)) {
handler_set_err(hdl, -ERANGE);
@@ -1352,7 +1359,10 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
v4l2_ctrl_handler *hdl,
ctrl->minimum = min;
ctrl->maximum = max;
ctrl->step = step;
- ctrl->qmenu = qmenu;
+ if (type == V4L2_CTRL_TYPE_MENU)
+ ctrl->qmenu = qmenu;
+ else if (type == V4L2_CTRL_TYPE_INTEGER_MENU)
+ ctrl->qmenu_int = qmenu_int;
ctrl->priv = priv;
ctrl->cur.val = ctrl->val = ctrl->default_value = def;
@@ -1379,6 +1389,7 @@ struct v4l2_ctrl *v4l2_ctrl_new_custom(struct
v4l2_ctrl_handler *hdl,
struct v4l2_ctrl *ctrl;
const char *name = cfg->name;
const char * const *qmenu = cfg->qmenu;
+ const s64 *qmenu_int = cfg->qmenu_int;
enum v4l2_ctrl_type type = cfg->type;
u32 flags = cfg->flags;
s32 min = cfg->min;
@@ -1390,18 +1401,24 @@ struct v4l2_ctrl *v4l2_ctrl_new_custom(struct
v4l2_ctrl_handler *hdl,
v4l2_ctrl_fill(cfg->id, &name, &type, &min, &max, &step,
&def, &flags);
- is_menu = (cfg->type == V4L2_CTRL_TYPE_MENU);
+ is_menu = (cfg->type == V4L2_CTRL_TYPE_MENU ||
+ cfg->type == V4L2_CTRL_TYPE_INTEGER_MENU);
if (is_menu)
WARN_ON(step);
else
WARN_ON(cfg->menu_skip_mask);
- if (is_menu && qmenu == NULL)
+ if (cfg->type == V4L2_CTRL_TYPE_MENU && qmenu == NULL)
qmenu = v4l2_ctrl_get_menu(cfg->id);
+ else if (cfg->type == V4L2_CTRL_TYPE_INTEGER_MENU &&
+qmenu_int == NULL) {
+ handler_set_err(hdl, -EINVAL);
+ return NULL;
+ }
ctrl = v4l2_ctrl_new(hdl, cfg->ops, cfg->id, name,
t
[RFC/PATCH 2/3] v4l: Document integer menu controls
Signed-off-by: Sakari Ailus --- Documentation/DocBook/media/v4l/compat.xml | 10 + Documentation/DocBook/media/v4l/v4l2.xml |7 .../DocBook/media/v4l/vidioc-queryctrl.xml | 39 +++- 3 files changed, 54 insertions(+), 2 deletions(-) diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index b68698f..569efd1 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml @@ -2379,6 +2379,16 @@ that used it. It was originally scheduled for removal in 2.6.35. + + V4L2 in Linux 3.3 + + + Added integer menus, the new type will be + V4L2_CTRL_TYPE_INTEGER_MENU. + + + + Relation of V4L2 to other Linux multimedia APIs diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml index 2ab365c..affe1ba 100644 --- a/Documentation/DocBook/media/v4l/v4l2.xml +++ b/Documentation/DocBook/media/v4l/v4l2.xml @@ -128,6 +128,13 @@ structs, ioctls) must be noted in more detail in the history chapter applications. --> + 3.3 + 2011-11-24 + sa + Added V4L2_CTRL_TYPE_INTEGER_MENU. + + + 3.2 2011-08-26 hv diff --git a/Documentation/DocBook/media/v4l/vidioc-queryctrl.xml b/Documentation/DocBook/media/v4l/vidioc-queryctrl.xml index 0ac0057..049cd46 100644 --- a/Documentation/DocBook/media/v4l/vidioc-queryctrl.xml +++ b/Documentation/DocBook/media/v4l/vidioc-queryctrl.xml @@ -215,11 +215,12 @@ the array to zero. struct v4l2_querymenu - + &cs-str; __u32 + id Identifies the control, set by the application from the respective &v4l2-queryctrl; @@ -227,18 +228,38 @@ from the respective &v4l2-queryctrl; __u32 + index Index of the menu item, starting at zero, set by the application. + union + + + + + + __u8 name[32] Name of the menu item, a NUL-terminated ASCII -string. This information is intended for the user. +string. This information is intended for the user. This field is valid +for V4L2_CTRL_FLAG_MENU type controls. + + + + __s64 + value + + Value of the integer menu item. This field is valid for + V4L2_CTRL_FLAG_INTEGER_MENU type + controls. + __u32 + reserved Reserved for future extensions. Drivers must set the array to zero. @@ -292,6 +313,20 @@ the menu items can be enumerated with the VIDIOC_QUERYMENU ioctl. + V4L2_CTRL_TYPE_INTEGER_MENU + ≥ 0 + 1 + N-1 + + The control has a menu of N choices. The names of the + menu items can be enumerated with the + VIDIOC_QUERYMENU ioctl. This is + similar to V4L2_CTRL_TYPE_MENU + except that instead of integers, the menu items are + signed 64-bit integers. + + + V4L2_CTRL_TYPE_BITMASK 0 n/a -- 1.7.2.5 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH 3/3] vivi: Add an integer menu test control
Add an integer menu test control for the vivi driver.
Signed-off-by: Sakari Ailus
---
drivers/media/video/vivi.c | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/vivi.c b/drivers/media/video/vivi.c
index 7d754fb..763ec23 100644
--- a/drivers/media/video/vivi.c
+++ b/drivers/media/video/vivi.c
@@ -177,6 +177,7 @@ struct vivi_dev {
struct v4l2_ctrl *menu;
struct v4l2_ctrl *string;
struct v4l2_ctrl *bitmask;
+ struct v4l2_ctrl *int_menu;
spinlock_t slock;
struct mutex mutex;
@@ -503,6 +504,10 @@ static void vivi_fillbuff(struct vivi_dev *dev, struct
vivi_buffer *buf)
dev->boolean->cur.val,
dev->menu->qmenu[dev->menu->cur.val],
dev->string->cur.string);
+ snprintf(str, sizeof(str), " integer_menu %s, value %lld ",
+ dev->int_menu->qmenu[dev->int_menu->cur.val],
+ dev->int64->cur.val64);
+ gen_text(dev, vbuf, line++ * 16, 16, str);
mutex_unlock(&dev->ctrl_handler.lock);
gen_text(dev, vbuf, line++ * 16, 16, str);
if (dev->button_pressed) {
@@ -1183,6 +1188,22 @@ static const struct v4l2_ctrl_config vivi_ctrl_bitmask =
{
.step = 0,
};
+static const s64 * const vivi_ctrl_int_menu_values[] = {
+ 1, 1, 2, 3, 5, 8, 13, 21, 42,
+};
+
+static const struct v4l2_ctrl_config vivi_ctrl_string = {
+ .ops = &vivi_ctrl_ops,
+ .id = VIDI_CID_CUSTOM_BASE + 7
+ .name = "Integer menu",
+ .type = V4L2_CTRL_TYPE_INTEGER_MENU,
+ .min = 1,
+ .max = 8,
+ .def = 4,
+ .menu_skip_mask = 0x02,
+ .qmenu_int = &vivi_ctrl_int_menu_values,
+};
+
static const struct v4l2_file_operations vivi_fops = {
.owner = THIS_MODULE,
.open = v4l2_fh_open,
--
1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH 0/3] 64-bit integer menus
Hi all, This patchset, which I'm sending as RFC since it has not been really tested (including compiling the vivi patch), adds 64-bit integer menu controls. The control items in the integer menu are just like in regular menus but they are 64-bit integers instead of strings. I'm also pondering whether to assign 1 to ctrl->step for menu type controls as well but haven't checked what may have been the original reason to implement it as it is now implemented. The reason why I don't use a union for qmenu and qmenu_int in v4l2_ctrl_config is that a lot of drivers use that field in the initialiser and GCC < 4.6 does not support initialisers with anonymous unions. Similar union is created in v4l2_querymenu but I do not see this as a problem since I do not expect initialisers to be used with this field in the user space code. Comments and questions are welcome. Kind regards, -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- 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/RFC 1/2] v4l: Add a global color alpha control
On 11/24/2011 03:00 PM, Laurent Pinchart wrote: > On Thursday 24 November 2011 13:22:10 Hans Verkuil wrote: >> On Thursday, November 24, 2011 13:06:09 Laurent Pinchart wrote: >>> On Thursday 24 November 2011 12:49:00 Hans Verkuil wrote: On Thursday, November 24, 2011 12:39:54 Sylwester Nawrocki wrote: > On 11/24/2011 12:09 PM, Laurent Pinchart wrote: >> On Thursday 24 November 2011 12:00:45 Hans Verkuil wrote: >>> On Thursday, November 24, 2011 11:53:16 Sylwester Nawrocki wrote: >> Well, if that's the case, then we already have an API for that >> (http://hverkuil.home.xs4all.nl/spec/media.html#v4l2-window, field >> global_alpha). >> >> It was my understanding that this is used with a mem2mem device where you >> just want to fill in the alpha channel to the desired value. It's not used >> inside the device at all (that happens later in the pipeline). > > OK, now I understand. Maybe the documentation should describe this a bit more > explicitly ? I've modified the control description so now it is: V4L2_CID_ALPHA_COMPONENT integer Sets the alpha color component on the capture device or on the capture buffer queue of a mem-to-mem device. It is applicable to any pixel formats that contain the alpha component, e.g. _packed RGB image_ formats. And the part below Table 2.6 Bit 7 is the most significant bit. The value of a = alpha bits is undefined when reading from the driver, ignored when writing to the driver, except when alpha blending has been negotiated for a Video Overlay or Video Output Overlay or when alpha component has been configured for a Video Capture by means of V4L2_CID_ALPHA_COMPONENT control. -- Regards, Sylwester -- 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/RFC 1/2] v4l: Add a global color alpha control
Hi, On Thursday 24 November 2011 13:22:10 Hans Verkuil wrote: > On Thursday, November 24, 2011 13:06:09 Laurent Pinchart wrote: > > On Thursday 24 November 2011 12:49:00 Hans Verkuil wrote: > > > On Thursday, November 24, 2011 12:39:54 Sylwester Nawrocki wrote: > > > > On 11/24/2011 12:09 PM, Laurent Pinchart wrote: > > > > > On Thursday 24 November 2011 12:00:45 Hans Verkuil wrote: > > > > >> On Thursday, November 24, 2011 11:53:16 Sylwester Nawrocki wrote: > > > > >>> This control is intended for video capture or memory-to-memory > > > > >>> devices that are capable of setting up the alpha conponent to > > > > >>> some arbitrary value. > > > > >>> The V4L2_CID_COLOR_ALPHA control allows to set the alpha channel > > > > >>> globally to a value in range from 0 to 255. > > > > >>> > > > > >>> Signed-off-by: Sylwester Nawrocki > > > > >>> Signed-off-by: Kyungmin Park > > > > >>> --- > > > > >>> > > > > >>> Documentation/DocBook/media/v4l/controls.xml | 20 > > > > >>> ++-- .../DocBook/media/v4l/pixfmt-packed-rgb.xml > > > > >>> > > > > >>> |7 +-- drivers/media/video/v4l2-ctrls.c > > > > >>> | | > > > > >>> > > > > >>> 7 +++ include/linux/videodev2.h | > > > > >>> 6 +++--- 4 files changed, 29 insertions(+), 11 deletions(-) > > > > >>> > > > > >>> diff --git a/Documentation/DocBook/media/v4l/controls.xml > > > > >>> b/Documentation/DocBook/media/v4l/controls.xml index > > > > >>> 3bc5ee8..7f99222 100644 > > > > >>> --- a/Documentation/DocBook/media/v4l/controls.xml > > > > >>> +++ b/Documentation/DocBook/media/v4l/controls.xml > > > > >>> @@ -324,12 +324,6 @@ minimum value disables backlight > > > > >>> compensation. > > > > >>> > > > > >>> (usually a microscope). > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> - V4L2_CID_LASTP1 > > > > >>> - > > > > >>> - End of the predefined control IDs (currently > > > > >>> -V4L2_CID_ILLUMINATORS_2 + 1). > > > > >>> - > > > > >>> - > > > > >>> > > > > >>> V4L2_CID_MIN_BUFFERS_FOR_CAPTURE > > > >>> > > > > >>> > > > > >>> > integer > > > > >>> > > > > >>> This is a read-only control that can be read by the > > > > >>> application > > > > >>> > > > > >>> @@ -345,6 +339,20 @@ and used as a hint to determine the number > > > > >>> of OUTPUT buffers to pass to REQBUFS. > > > > >>> > > > > >>> The value is the minimum number of OUTPUT buffers that is > > > > >>> necessary for hardware to work. > > > > >>> > > > > >>> > > > > >>> > > > > >>> + > > > > >>> + V4L2_CID_COLOR_ALPHA > > > > >>> + integer > > > > >>> +Sets the color alpha component on the capture > > > > >>> device. It is + applicable to any pixel formats that contain > > > > >>> the alpha component, + e.g. > > > >>> linkend="rgb-formats">packed RGB image formats. + > > > > >>> > > > > > > > > > > As the alpha value is global, isn't it applicable to formats with > > > > > no alpha component as well ? > > > > > > > > Hmm, I can't say no.. The control was intended as a means of setting > > > > up the alpha value for packed RGB formats: > > > > http://linuxtv.org/downloads/v4l-dvb-apis/packed-rgb.html#rgb-formats > > > > > > > > However it could well be used for formats with no alpha. Do you think > > > > the second sentence above should be removed or should something else > > > > be added to indicate it doesn't necessarily have to have a > > > > connection with ARGB color formats ? > > > > I think we should make it explicit that this global alpha value is > > applied in addition to a possibly per-pixel alpha value (if available in > > the selected format). > > > > > Huh? How can this be used for formats without an alpha channel? > > > > If my understanding is correct, this control sets a global alpha value > > for the whole overlay. For instance, with V4L2_CID_COLOR_ALPHA set to > > 0.5, an overlay using a non-alpha format (such as YUYV), or an overlay > > using an alpha format with the alpha value set to 1 for every pixel, > > would be half transparent. > > > > In other words, the resulting alpha value is the product of the global > > alpha value and the per-pixel alpha value. Non-alpha formats have an > > implicit per- pixel alpha value equal to 1 for every pixel. > > Well, if that's the case, then we already have an API for that > (http://hverkuil.home.xs4all.nl/spec/media.html#v4l2-window, field > global_alpha). > > It was my understanding that this is used with a mem2mem device where you > just want to fill in the alpha channel to the desired value. It's not used > inside the device at all (that happens later in the pipeline). OK, now I understand. Maybe the documentation should describe this a bit more explicitly ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubsc
Re: [PATCH/RFC 1/2] v4l: Add a global color alpha control
On 11/24/2011 12:49 PM, Hans Verkuil wrote: > On Thursday, November 24, 2011 12:39:54 Sylwester Nawrocki wrote: >> On 11/24/2011 12:09 PM, Laurent Pinchart wrote: >>> On Thursday 24 November 2011 12:00:45 Hans Verkuil wrote: On Thursday, November 24, 2011 11:53:16 Sylwester Nawrocki wrote: ... > How about V4L2_CID_ALPHA_COMPONENT? This one seems the best fit for me. I'll redo the patches and send them out tomorrow. Unless someone comes up with even better name. Thanks for your comment Hans and Laurent! -- Regards, Sylwester -- 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
[RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.
From: Hans Verkuil
Signed-off-by: Hans Verkuil
---
fs/compat_ioctl.c | 41 +---
include/linux/dvb/Kbuild |3 -
include/linux/dvb/audio.h | 135 --
include/linux/dvb/osd.h | 144 ---
include/linux/dvb/video.h | 276 -
5 files changed, 1 insertions(+), 598 deletions(-)
delete mode 100644 include/linux/dvb/audio.h
delete mode 100644 include/linux/dvb/osd.h
delete mode 100644 include/linux/dvb/video.h
diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
index 51352de..71adea1 100644
--- a/fs/compat_ioctl.c
+++ b/fs/compat_ioctl.c
@@ -105,10 +105,9 @@
#include
-#include
+#include
#include
#include
-#include
#include
@@ -196,32 +195,6 @@ static int do_video_stillpicture(unsigned int fd, unsigned
int cmd,
return err;
}
-struct compat_video_spu_palette {
- int length;
- compat_uptr_t palette;
-};
-
-static int do_video_set_spu_palette(unsigned int fd, unsigned int cmd,
- struct compat_video_spu_palette __user *up)
-{
- struct video_spu_palette __user *up_native;
- compat_uptr_t palp;
- int length, err;
-
- err = get_user(palp, &up->palette);
- err |= get_user(length, &up->length);
-
- up_native = compat_alloc_user_space(sizeof(struct video_spu_palette));
- err = put_user(compat_ptr(palp), &up_native->palette);
- err |= put_user(length, &up_native->length);
- if (err)
- return -EFAULT;
-
- err = sys_ioctl(fd, cmd, (unsigned long) up_native);
-
- return err;
-}
-
#ifdef CONFIG_BLOCK
typedef struct sg_io_hdr32 {
compat_int_t interface_id; /* [i] 'S' for SCSI generic (required)
*/
@@ -1317,9 +1290,6 @@ COMPATIBLE_IOCTL(AUDIO_CLEAR_BUFFER)
COMPATIBLE_IOCTL(AUDIO_SET_ID)
COMPATIBLE_IOCTL(AUDIO_SET_MIXER)
COMPATIBLE_IOCTL(AUDIO_SET_STREAMTYPE)
-COMPATIBLE_IOCTL(AUDIO_SET_EXT_ID)
-COMPATIBLE_IOCTL(AUDIO_SET_ATTRIBUTES)
-COMPATIBLE_IOCTL(AUDIO_SET_KARAOKE)
COMPATIBLE_IOCTL(DMX_START)
COMPATIBLE_IOCTL(DMX_STOP)
COMPATIBLE_IOCTL(DMX_SET_FILTER)
@@ -1358,16 +1328,9 @@ COMPATIBLE_IOCTL(VIDEO_FAST_FORWARD)
COMPATIBLE_IOCTL(VIDEO_SLOWMOTION)
COMPATIBLE_IOCTL(VIDEO_GET_CAPABILITIES)
COMPATIBLE_IOCTL(VIDEO_CLEAR_BUFFER)
-COMPATIBLE_IOCTL(VIDEO_SET_ID)
COMPATIBLE_IOCTL(VIDEO_SET_STREAMTYPE)
COMPATIBLE_IOCTL(VIDEO_SET_FORMAT)
-COMPATIBLE_IOCTL(VIDEO_SET_SYSTEM)
-COMPATIBLE_IOCTL(VIDEO_SET_HIGHLIGHT)
-COMPATIBLE_IOCTL(VIDEO_SET_SPU)
-COMPATIBLE_IOCTL(VIDEO_GET_NAVI)
-COMPATIBLE_IOCTL(VIDEO_SET_ATTRIBUTES)
COMPATIBLE_IOCTL(VIDEO_GET_SIZE)
-COMPATIBLE_IOCTL(VIDEO_GET_FRAME_RATE)
/* joystick */
COMPATIBLE_IOCTL(JSIOCGVERSION)
@@ -1468,8 +1431,6 @@ static long do_ioctl_trans(int fd, unsigned int cmd,
return do_video_get_event(fd, cmd, argp);
case VIDEO_STILLPICTURE:
return do_video_stillpicture(fd, cmd, argp);
- case VIDEO_SET_SPU_PALETTE:
- return do_video_set_spu_palette(fd, cmd, argp);
}
/*
diff --git a/include/linux/dvb/Kbuild b/include/linux/dvb/Kbuild
index f4dba86..f5aa137 100644
--- a/include/linux/dvb/Kbuild
+++ b/include/linux/dvb/Kbuild
@@ -1,8 +1,5 @@
-header-y += audio.h
header-y += ca.h
header-y += dmx.h
header-y += frontend.h
header-y += net.h
-header-y += osd.h
header-y += version.h
-header-y += video.h
diff --git a/include/linux/dvb/audio.h b/include/linux/dvb/audio.h
deleted file mode 100644
index d47bccd..000
--- a/include/linux/dvb/audio.h
+++ /dev/null
@@ -1,135 +0,0 @@
-/*
- * audio.h
- *
- * Copyright (C) 2000 Ralph Metzler
- * & Marcus Metzler
- *for convergence integrated media GmbH
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Lesser Public License
- * as published by the Free Software Foundation; either version 2.1
- * of the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
- *
- */
-
-#ifndef _DVBAUDIO_H_
-#define _DVBAUDIO_H_
-
-#include
-
-typedef enum {
- AUDIO_SOURCE_DEMUX, /* Select the demux as the main source */
- AUDIO_SOURCE_MEMORY /* Select internal memory as the main source */
-} audio_stream_source_t;
-
-
-typedef enum {
- AUDIO_STOPPED, /* Device is stopped */
- AUDIO_PLAYING, /* Device is currently playing */
- AUDIO_PAUSED/* Device is paused */
-} audio_play_state_t;
-
-
-typedef enum {
- AUDIO_ST
[RFCv2 PATCH 07/12] cx18/ddbridge: remove unused headers.
From: Hans Verkuil Work is in progress to deprecate include/linux/dvb/audio.h and video.h. The cx18 and ddbridge drivers include these headers without using them. Remove those includes. Signed-off-by: Hans Verkuil --- drivers/media/dvb/ddbridge/ddbridge.h |2 -- drivers/media/video/cx18/cx18-driver.h |2 -- 2 files changed, 0 insertions(+), 4 deletions(-) diff --git a/drivers/media/dvb/ddbridge/ddbridge.h b/drivers/media/dvb/ddbridge/ddbridge.h index 6d14893..8b1b41d 100644 --- a/drivers/media/dvb/ddbridge/ddbridge.h +++ b/drivers/media/dvb/ddbridge/ddbridge.h @@ -32,8 +32,6 @@ #include #include #include -#include -#include #include #include "dmxdev.h" diff --git a/drivers/media/video/cx18/cx18-driver.h b/drivers/media/video/cx18/cx18-driver.h index b9a94fc..7a37e0e 100644 --- a/drivers/media/video/cx18/cx18-driver.h +++ b/drivers/media/video/cx18/cx18-driver.h @@ -44,8 +44,6 @@ #include #include -#include -#include #include #include #include -- 1.7.7.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
[RFCv2 PATCH 03/12] ivtv: implement new decoder command ioctls.
From: Hans Verkuil
Signed-off-by: Hans Verkuil
---
drivers/media/video/ivtv/ivtv-driver.c |2 +-
drivers/media/video/ivtv/ivtv-fileops.c |2 +-
drivers/media/video/ivtv/ivtv-ioctl.c | 106 +++---
drivers/media/video/ivtv/ivtv-streams.c |4 +-
4 files changed, 71 insertions(+), 43 deletions(-)
diff --git a/drivers/media/video/ivtv/ivtv-driver.c
b/drivers/media/video/ivtv/ivtv-driver.c
index 41108a9..7ee7594 100644
--- a/drivers/media/video/ivtv/ivtv-driver.c
+++ b/drivers/media/video/ivtv/ivtv-driver.c
@@ -1378,7 +1378,7 @@ static void ivtv_remove(struct pci_dev *pdev)
else
type = IVTV_DEC_STREAM_TYPE_MPG;
ivtv_stop_v4l2_decode_stream(&itv->streams[type],
- VIDEO_CMD_STOP_TO_BLACK |
VIDEO_CMD_STOP_IMMEDIATELY, 0);
+ V4L2_DEC_CMD_STOP_TO_BLACK |
V4L2_DEC_CMD_STOP_IMMEDIATELY, 0);
}
ivtv_halt_firmware(itv);
}
diff --git a/drivers/media/video/ivtv/ivtv-fileops.c
b/drivers/media/video/ivtv/ivtv-fileops.c
index 38f0522..66228ee 100644
--- a/drivers/media/video/ivtv/ivtv-fileops.c
+++ b/drivers/media/video/ivtv/ivtv-fileops.c
@@ -899,7 +899,7 @@ int ivtv_v4l2_close(struct file *filp)
} else if (s->type >= IVTV_DEC_STREAM_TYPE_MPG) {
struct ivtv_stream *s_vout =
&itv->streams[IVTV_DEC_STREAM_TYPE_VOUT];
- ivtv_stop_decoding(id, VIDEO_CMD_STOP_TO_BLACK |
VIDEO_CMD_STOP_IMMEDIATELY, 0);
+ ivtv_stop_decoding(id, V4L2_DEC_CMD_STOP_TO_BLACK |
V4L2_DEC_CMD_STOP_IMMEDIATELY, 0);
/* If all output streams are closed, and if the user doesn't
have
IVTV_DEC_STREAM_TYPE_VOUT open, then disable CC on TV-out. */
diff --git a/drivers/media/video/ivtv/ivtv-ioctl.c
b/drivers/media/video/ivtv/ivtv-ioctl.c
index ecafa69..c84e325 100644
--- a/drivers/media/video/ivtv/ivtv-ioctl.c
+++ b/drivers/media/video/ivtv/ivtv-ioctl.c
@@ -244,34 +244,40 @@ static int ivtv_validate_speed(int cur_speed, int
new_speed)
}
static int ivtv_video_command(struct ivtv *itv, struct ivtv_open_id *id,
- struct video_command *vc, int try)
+ struct v4l2_decoder_cmd *dc, int try)
{
struct ivtv_stream *s = &itv->streams[IVTV_DEC_STREAM_TYPE_MPG];
if (!(itv->v4l2_cap & V4L2_CAP_VIDEO_OUTPUT))
return -EINVAL;
- switch (vc->cmd) {
- case VIDEO_CMD_PLAY: {
- vc->flags = 0;
- vc->play.speed = ivtv_validate_speed(itv->speed,
vc->play.speed);
- if (vc->play.speed < 0)
- vc->play.format = VIDEO_PLAY_FMT_GOP;
+ switch (dc->cmd) {
+ case V4L2_DEC_CMD_START: {
+ dc->flags &= V4L2_DEC_CMD_START_MUTE_AUDIO;
+ dc->start.speed = ivtv_validate_speed(itv->speed,
dc->start.speed);
+ if (dc->start.speed < 0)
+ dc->start.format = V4L2_DEC_START_FMT_GOP;
+ else
+ dc->start.format = V4L2_DEC_START_FMT_NONE;
+ if (dc->start.speed != 500 && dc->start.speed != 1500)
+ dc->flags = dc->start.speed == 1000 ? 0 :
+ V4L2_DEC_CMD_START_MUTE_AUDIO;
if (try) break;
+ itv->speed_mute_audio = dc->flags &
V4L2_DEC_CMD_START_MUTE_AUDIO;
if (ivtv_set_output_mode(itv, OUT_MPG) != OUT_MPG)
return -EBUSY;
if (test_and_clear_bit(IVTV_F_I_DEC_PAUSED, &itv->i_flags)) {
/* forces ivtv_set_speed to be called */
itv->speed = 0;
}
- return ivtv_start_decoding(id, vc->play.speed);
+ return ivtv_start_decoding(id, dc->start.speed);
}
- case VIDEO_CMD_STOP:
- vc->flags &= VIDEO_CMD_STOP_IMMEDIATELY|VIDEO_CMD_STOP_TO_BLACK;
- if (vc->flags & VIDEO_CMD_STOP_IMMEDIATELY)
- vc->stop.pts = 0;
+ case V4L2_DEC_CMD_STOP:
+ dc->flags &= V4L2_DEC_CMD_STOP_IMMEDIATELY |
V4L2_DEC_CMD_STOP_TO_BLACK;
+ if (dc->flags & V4L2_DEC_CMD_STOP_IMMEDIATELY)
+ dc->stop.pts = 0;
if (try) break;
if (atomic_read(&itv->decoding) == 0)
return 0;
@@ -279,22 +285,22 @@ static int ivtv_video_command(struct ivtv *itv, struct
ivtv_open_id *id,
return -EBUSY;
itv->output_mode = OUT_NONE;
- return ivtv_stop_v4l2_decode_stream(s, vc->flags, vc->stop.pts);
+ return ivtv_stop_v4l2_decode_stream(s, dc->flags, dc->stop.pts);
- case VIDEO_CMD_FREEZE:
- vc->flags &= VIDEO_CMD_FREEZE_TO_BLACK;
+ case V4L2_DEC_CMD_PAUSE:
+ dc->flags &= V4L2_DEC_C
[RFCv2 PATCH 09/12] ivtv: use the new ivtv-specific ioctls from ivtv.h.
From: Hans Verkuil
The ivtv driver now no longer uses dvb/audio.h and dvb/video.h.
Signed-off-by: Hans Verkuil
---
drivers/media/video/ivtv/ivtv-driver.h |2 -
drivers/media/video/ivtv/ivtv-ioctl.c | 127 +---
2 files changed, 67 insertions(+), 62 deletions(-)
diff --git a/drivers/media/video/ivtv/ivtv-driver.h
b/drivers/media/video/ivtv/ivtv-driver.h
index ef5ed32..0d2f31c 100644
--- a/drivers/media/video/ivtv/ivtv-driver.h
+++ b/drivers/media/video/ivtv/ivtv-driver.h
@@ -57,8 +57,6 @@
#include
#include
-#include
-#include
#include
#include
#include
diff --git a/drivers/media/video/ivtv/ivtv-ioctl.c
b/drivers/media/video/ivtv/ivtv-ioctl.c
index 736ba8e..fb66173 100644
--- a/drivers/media/video/ivtv/ivtv-ioctl.c
+++ b/drivers/media/video/ivtv/ivtv-ioctl.c
@@ -36,7 +36,6 @@
#include
#include
#include
-#include
u16 ivtv_service2vbi(int type)
{
@@ -1618,11 +1617,17 @@ static int ivtv_decoder_ioctls(struct file *filp,
unsigned int cmd, void *arg)
return ivtv_yuv_prep_frame(itv, args);
}
- case VIDEO_GET_PTS: {
+ case IVTV_IOC_PASSTHROUGH_MODE:
+ IVTV_DEBUG_IOCTL("IVTV_IOC_PASSTHROUGH_MODE\n");
+ if (!(itv->v4l2_cap & V4L2_CAP_VIDEO_OUTPUT))
+ return -EINVAL;
+ return ivtv_passthrough_mode(itv, *(int *)arg != 0);
+
+ case IVTV_VIDEO_GET_PTS: {
s64 *pts = arg;
s64 frame;
- IVTV_DEBUG_IOCTL("VIDEO_GET_PTS\n");
+ IVTV_DEBUG_IOCTL("IVTV_VIDEO_GET_PTS\n");
if (s->type < IVTV_DEC_STREAM_TYPE_MPG) {
*pts = s->dma_pts;
break;
@@ -1632,11 +1637,11 @@ static int ivtv_decoder_ioctls(struct file *filp,
unsigned int cmd, void *arg)
return ivtv_g_pts_frame(itv, pts, &frame);
}
- case VIDEO_GET_FRAME_COUNT: {
+ case IVTV_VIDEO_GET_FRAME_COUNT: {
s64 *frame = arg;
s64 pts;
- IVTV_DEBUG_IOCTL("VIDEO_GET_FRAME_COUNT\n");
+ IVTV_DEBUG_IOCTL("IVTV_VIDEO_GET_FRAME_COUNT\n");
if (s->type < IVTV_DEC_STREAM_TYPE_MPG) {
*frame = 0;
break;
@@ -1646,62 +1651,62 @@ static int ivtv_decoder_ioctls(struct file *filp,
unsigned int cmd, void *arg)
return ivtv_g_pts_frame(itv, &pts, frame);
}
- case VIDEO_PLAY: {
+ case IVTV_VIDEO_PLAY: {
struct v4l2_decoder_cmd dc;
- IVTV_DEBUG_IOCTL("VIDEO_PLAY\n");
+ IVTV_DEBUG_IOCTL("IVTV_VIDEO_PLAY\n");
memset(&dc, 0, sizeof(dc));
dc.cmd = V4L2_DEC_CMD_START;
return ivtv_video_command(itv, id, &dc, 0);
}
- case VIDEO_STOP: {
+ case IVTV_VIDEO_STOP: {
struct v4l2_decoder_cmd dc;
- IVTV_DEBUG_IOCTL("VIDEO_STOP\n");
+ IVTV_DEBUG_IOCTL("IVTV_VIDEO_STOP\n");
memset(&dc, 0, sizeof(dc));
dc.cmd = V4L2_DEC_CMD_STOP;
dc.flags = V4L2_DEC_CMD_STOP_TO_BLACK |
V4L2_DEC_CMD_STOP_IMMEDIATELY;
return ivtv_video_command(itv, id, &dc, 0);
}
- case VIDEO_FREEZE: {
+ case IVTV_VIDEO_FREEZE: {
struct v4l2_decoder_cmd dc;
- IVTV_DEBUG_IOCTL("VIDEO_FREEZE\n");
+ IVTV_DEBUG_IOCTL("IVTV_VIDEO_FREEZE\n");
memset(&dc, 0, sizeof(dc));
dc.cmd = V4L2_DEC_CMD_PAUSE;
return ivtv_video_command(itv, id, &dc, 0);
}
- case VIDEO_CONTINUE: {
+ case IVTV_VIDEO_CONTINUE: {
struct v4l2_decoder_cmd dc;
- IVTV_DEBUG_IOCTL("VIDEO_CONTINUE\n");
+ IVTV_DEBUG_IOCTL("IVTV_VIDEO_CONTINUE\n");
memset(&dc, 0, sizeof(dc));
dc.cmd = V4L2_DEC_CMD_RESUME;
return ivtv_video_command(itv, id, &dc, 0);
}
- case VIDEO_COMMAND:
- case VIDEO_TRY_COMMAND: {
+ case IVTV_VIDEO_COMMAND:
+ case IVTV_VIDEO_TRY_COMMAND: {
/* Note: struct v4l2_decoder_cmd has the same layout as
struct video_command */
struct v4l2_decoder_cmd *dc = arg;
- int try = (cmd == VIDEO_TRY_COMMAND);
+ int try = (cmd == IVTV_VIDEO_TRY_COMMAND);
if (try)
- IVTV_DEBUG_IOCTL("VIDEO_TRY_COMMAND %d\n", dc->cmd);
+ IVTV_DEBUG_IOCTL("IVTV_VIDEO_TRY_COMMAND %d\n",
dc->cmd);
else
- IVTV_DEBUG_IOCTL("VIDEO_COMMAND %d\n", dc->cmd);
+ IVTV_DEBUG_IOCTL("IVTV_VIDEO_COMMAND %d\n", dc->cmd);
return ivtv_video_command(itv, id, dc, try);
}
- case VIDEO_GET_EVENT: {
- struct video_event *ev = ar
[RFCv2 PATCH 08/12] ivtv: extend ivtv.h with structs and ioctls from dvb/audio.h and video.h.
From: Hans Verkuil
This removes the ivtv dependency on those dvb headers.
Signed-off-by: Hans Verkuil
---
include/linux/ivtv.h | 86 +-
1 files changed, 85 insertions(+), 1 deletions(-)
diff --git a/include/linux/ivtv.h b/include/linux/ivtv.h
index 062d20f..dacb712 100644
--- a/include/linux/ivtv.h
+++ b/include/linux/ivtv.h
@@ -58,7 +58,8 @@ struct ivtv_dma_frame {
__u32 src_height;
};
-#define IVTV_IOC_DMA_FRAME _IOW ('V', BASE_VIDIOC_PRIVATE+0, struct
ivtv_dma_frame)
+#define IVTV_IOC_DMA_FRAME _IOW ('V', BASE_VIDIOC_PRIVATE+0,
struct ivtv_dma_frame)
+#define IVTV_IOC_PASSTHROUGH_MODE _IOW ('V', BASE_VIDIOC_PRIVATE+1, int)
/* Deprecated defines: applications should use the defines from videodev2.h */
#define IVTV_SLICED_TYPE_TELETEXT_B V4L2_MPEG_VBI_IVTV_TELETEXT_B
@@ -66,4 +67,87 @@ struct ivtv_dma_frame {
#define IVTV_SLICED_TYPE_WSS_625V4L2_MPEG_VBI_IVTV_WSS_625
#define IVTV_SLICED_TYPE_VPSV4L2_MPEG_VBI_IVTV_VPS
+
+/* The code below used to be part of the DVBv5 API as was defined in the
+ linux/dvb/audio.h and video.h headers.
+
+ That API was only used by av7110 and ivtv and the decision was made to
+ deprecate that decoder API and replace it with a proper V4L2 API in the
+ case of ivtv.
+
+ For the time being the part of those headers that ivtv uses is copied in
+ this header and renamed with an IVTV_ prefix. At some point in the future
+ this API will probably be removed.
+
+ The replacement V4L2 API appeared in kernel 3.3. How to convert applications
+ from the old DVBv5 API to the new V4L2 API is described below. */
+
+/* Should the audio be muted when doing playback at non-standard speeds?
+ Replaced by the V4L2_DEC_CMD_START_MUTE_AUDIO flag. */
+#define IVTV_AUDIO_SET_MUTE _IO('o', 6)
+
+/* Channel selection during playback.
+ Replaced by the V4L2_CID_MPEG_AUDIO_DEC_PLAYBACK and
+ V4L2_CID_MPEG_AUDIO_DEC_MULTILINGUAL_PLAYBACK controls. */
+#define IVTV_AUDIO_STEREO (0)
+#define IVTV_AUDIO_MONO_LEFT (1)
+#define IVTV_AUDIO_MONO_RIGHT (2)
+#define IVTV_AUDIO_MONO(3)
+#define IVTV_AUDIO_STEREO_SWAPPED (4)
+
+#define IVTV_AUDIO_CHANNEL_SELECT _IO('o', 9)
+#define IVTV_AUDIO_BILINGUAL_CHANNEL_SELECT _IO('o', 20)
+
+/* Video playback. Replaced by the VIDIOC_(TRY_)DECODER_CMD ioctls. */
+#define IVTV_VIDEO_STOP _IO('o', 21)
+#define IVTV_VIDEO_PLAY _IO('o', 22)
+#define IVTV_VIDEO_FREEZE _IO('o', 23)
+#define IVTV_VIDEO_CONTINUE _IO('o', 24)
+#define IVTV_VIDEO_COMMAND _IOWR('o', 59, struct v4l2_decoder_cmd)
+#define IVTV_VIDEO_TRY_COMMAND _IOWR('o', 60, struct v4l2_decoder_cmd)
+
+/* Select passthrough mode. Replaced by the ivtv-private
+ IVTV_IOC_PASSTHROUGH_MODE ioctl. */
+#define IVTV_VIDEO_SOURCE_DEMUX(0)
+#define IVTV_VIDEO_SOURCE_MEMORY (1)
+#define IVTV_VIDEO_SELECT_SOURCE_IO('o', 25)
+
+/* Event handling. Replaced by the V4L2 event API (VIDIOC_DQEVENT et al.)
+ *
+ * This ioctl call returns an event of type video_event if available. If an
+ * event is not available, the behavior depends on whether the device is in
+ * blocking or non-blocking mode. In the latter case, the call fails
immediately
+ * with errno set to EWOULDBLOCK. In the former case, the call blocks until an
+ * event becomes available. The standard Linux poll() and/or select() system
+ * calls can be used with the device file descriptor to watch for new events.
+ * For select(), the file descriptor should be included in the exceptfds
+ * argument, and for poll(), POLLPRI should be specified as the wake-up
+ * condition. Read-only permissions are sufficient for this ioctl call.
+ */
+
+/* FIELD_UNKNOWN can be used if the hardware does not know whether
+ the Vsync is for an odd, even or progressive (i.e. non-interlaced)
+ field. */
+#define IVTV_VIDEO_VSYNC_FIELD_UNKNOWN (0)
+#define IVTV_VIDEO_VSYNC_FIELD_ODD (1)
+#define IVTV_VIDEO_VSYNC_FIELD_EVEN(2)
+#define IVTV_VIDEO_VSYNC_FIELD_PROGRESSIVE (3)
+
+struct ivtv_video_event {
+ __s32 type;
+#define IVTV_VIDEO_EVENT_DECODER_STOPPED (3)
+#define IVTV_VIDEO_EVENT_VSYNC (4)
+ __kernel_time_t timestamp;
+ union {
+ unsigned char vsync_field; /* unknown/odd/even/progressive
*/
+ } u;
+};
+#define IVTV_VIDEO_GET_EVENT _IOR('o', 28, struct ivtv_video_event)
+
+/* Returns the PTS and frame count of the frame that's being decoded or
+ displayed. Replaced by the V4L2_CID_MPEG_STREAM_DEC_PTS and
+ V4L2_CID_MPEG_VIDEO_DEC_FRAME read-only controls. */
+#define IVTV_VIDEO_GET_PTS _IOR('o', 57, __u64)
+#define IVTV_VIDEO_GET_FRAME_COUNT _IOR('o', 58, __u64)
+
#endif /* _LINUX_IVTV_H */
--
1.7.7.3
--
To unsubscribe from this lis
[RFCv2 PATCH 05/12] Document decoder controls.
From: Hans Verkuil Signed-off-by: Hans Verkuil --- Documentation/DocBook/media/v4l/controls.xml | 58 ++ 1 files changed, 58 insertions(+), 0 deletions(-) diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index 3bc5ee8..411fba2 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -797,6 +797,13 @@ in the kernel sources in the file Documentation/video4linux/cx2341x/RE + + V4L2_CID_MPEG_STREAM_DEC_PTS + integer64 + This read-only control returns the +Program Time Stamp of the frame that is currently displayed (decoded). + + V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ enum v4l2_mpeg_audio_sampling_freq @@ -1273,6 +1280,49 @@ produce a slight hiss, but in the encoder itself, guaranteeing a fixed and reproducible audio bitstream. 0 = unmuted, 1 = muted. + + V4L2_CID_MPEG_AUDIO_DEC_PLAYBACK + enum v4l2_mpeg_audio_dec_playback + Determines how monolingual audio should be played back. +Possible values are: + + + + + + V4L2_MPEG_AUDIO_DEC_PLAYBACK_AUTO + Automatically determines the best playback mode. + + + V4L2_MPEG_AUDIO_DEC_PLAYBACK_STEREO + Stereo playback. + + + V4L2_MPEG_AUDIO_DEC_PLAYBACK_LEFT + Left channel playback. + + + V4L2_MPEG_AUDIO_DEC_PLAYBACK_RIGHT + Right channel playback. + + + V4L2_MPEG_AUDIO_DEC_PLAYBACK_MONO + Mono playback. + + + V4L2_MPEG_AUDIO_DEC_PLAYBACK_SWAPPED_STEREO + Stereo playback with swapped left and right channels. + + + + + + + V4L2_CID_MPEG_AUDIO_DEC_MULTILINGUAL_PLAYBACK + enum v4l2_mpeg_audio_dec_playback + Determines how multilingual audio should be played back. + + V4L2_CID_MPEG_VIDEO_ENCODING enum v4l2_mpeg_video_encoding @@ -1434,6 +1484,14 @@ of the video. The supplied 32-bit integer is interpreted as follows (bit + + + V4L2_CID_MPEG_VIDEO_DEC_FRAME + integer64 + This read-only control returns the +frame counter of the frame that is currently displayed (decoded). This value is reset to 0 whenever +the decoder is started. + -- 1.7.7.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
[RFCv2 PATCH 06/12] ivtv: implement new decoder controls.
From: Hans Verkuil
Signed-off-by: Hans Verkuil
---
drivers/media/video/ivtv/ivtv-controls.c | 62 +++
drivers/media/video/ivtv/ivtv-controls.h |2 +
drivers/media/video/ivtv/ivtv-driver.c | 35 +++-
drivers/media/video/ivtv/ivtv-driver.h | 12 +-
drivers/media/video/ivtv/ivtv-ioctl.c| 67 +
drivers/media/video/ivtv/ivtv-streams.c |5 ++-
6 files changed, 124 insertions(+), 59 deletions(-)
diff --git a/drivers/media/video/ivtv/ivtv-controls.c
b/drivers/media/video/ivtv/ivtv-controls.c
index b31ee1b..5fb91b9 100644
--- a/drivers/media/video/ivtv/ivtv-controls.c
+++ b/drivers/media/video/ivtv/ivtv-controls.c
@@ -21,6 +21,7 @@
#include "ivtv-driver.h"
#include "ivtv-ioctl.h"
#include "ivtv-controls.h"
+#include "ivtv-mailbox.h"
static int ivtv_s_stream_vbi_fmt(struct cx2341x_handler *cxhdl, u32 fmt)
{
@@ -99,3 +100,64 @@ struct cx2341x_handler_ops ivtv_cxhdl_ops = {
.s_video_encoding = ivtv_s_video_encoding,
.s_stream_vbi_fmt = ivtv_s_stream_vbi_fmt,
};
+
+int ivtv_g_pts_frame(struct ivtv *itv, s64 *pts, s64 *frame)
+{
+ u32 data[CX2341X_MBOX_MAX_DATA];
+
+ if (test_bit(IVTV_F_I_VALID_DEC_TIMINGS, &itv->i_flags)) {
+ *pts = (s64)((u64)itv->last_dec_timing[2] << 32) |
+ (u64)itv->last_dec_timing[1];
+ *frame = itv->last_dec_timing[0];
+ return 0;
+ }
+ *pts = 0;
+ *frame = 0;
+ if (atomic_read(&itv->decoding)) {
+ if (ivtv_api(itv, CX2341X_DEC_GET_TIMING_INFO, 5, data)) {
+ IVTV_DEBUG_WARN("GET_TIMING: couldn't read clock\n");
+ return -EIO;
+ }
+ memcpy(itv->last_dec_timing, data,
sizeof(itv->last_dec_timing));
+ set_bit(IVTV_F_I_VALID_DEC_TIMINGS, &itv->i_flags);
+ *pts = (s64)((u64) data[2] << 32) | (u64) data[1];
+ *frame = data[0];
+ /*timing->scr = (u64) (((u64) data[4] << 32) | (u64)
(data[3]));*/
+ }
+ return 0;
+}
+
+static int ivtv_g_volatile_ctrl(struct v4l2_ctrl *ctrl)
+{
+ struct ivtv *itv = container_of(ctrl->handler, struct ivtv, hdl_out);
+
+ switch (ctrl->id) {
+ /* V4L2_CID_MPEG_STREAM_DEC_PTS and V4L2_CID_MPEG_VIDEO_DEC_FRAME
+ control cluster */
+ case V4L2_CID_MPEG_STREAM_DEC_PTS:
+ return ivtv_g_pts_frame(itv, &itv->ctrl_pts->val64,
+&itv->ctrl_frame->val64);
+ }
+ return 0;
+}
+
+static int ivtv_s_ctrl(struct v4l2_ctrl *ctrl)
+{
+ struct ivtv *itv = container_of(ctrl->handler, struct ivtv, hdl_out);
+
+ switch (ctrl->id) {
+ /* V4L2_CID_MPEG_AUDIO_DEC_PLAYBACK and MULTILINGUAL_PLAYBACK
+ control cluster */
+ case V4L2_CID_MPEG_AUDIO_DEC_PLAYBACK:
+ itv->audio_stereo_mode = itv->ctrl_audio_playback->val - 1;
+ itv->audio_bilingual_mode =
itv->ctrl_audio_multilingual_playback->val - 1;
+ ivtv_vapi(itv, CX2341X_DEC_SET_AUDIO_MODE, 2,
itv->audio_bilingual_mode, itv->audio_stereo_mode);
+ break;
+ }
+ return 0;
+}
+
+const struct v4l2_ctrl_ops ivtv_hdl_out_ops = {
+ .s_ctrl = ivtv_s_ctrl,
+ .g_volatile_ctrl = ivtv_g_volatile_ctrl,
+};
diff --git a/drivers/media/video/ivtv/ivtv-controls.h
b/drivers/media/video/ivtv/ivtv-controls.h
index d12893d..3999e63 100644
--- a/drivers/media/video/ivtv/ivtv-controls.h
+++ b/drivers/media/video/ivtv/ivtv-controls.h
@@ -22,5 +22,7 @@
#define IVTV_CONTROLS_H
extern struct cx2341x_handler_ops ivtv_cxhdl_ops;
+extern const struct v4l2_ctrl_ops ivtv_hdl_out_ops;
+int ivtv_g_pts_frame(struct ivtv *itv, s64 *pts, s64 *frame);
#endif
diff --git a/drivers/media/video/ivtv/ivtv-driver.c
b/drivers/media/video/ivtv/ivtv-driver.c
index 7ee7594..1464a9c 100644
--- a/drivers/media/video/ivtv/ivtv-driver.c
+++ b/drivers/media/video/ivtv/ivtv-driver.c
@@ -747,8 +747,6 @@ static int __devinit ivtv_init_struct1(struct ivtv *itv)
itv->cur_dma_stream = -1;
itv->cur_pio_stream = -1;
- itv->audio_stereo_mode = AUDIO_STEREO;
- itv->audio_bilingual_mode = AUDIO_MONO_LEFT;
/* Ctrls */
itv->speed = 1000;
@@ -1203,6 +1201,32 @@ static int __devinit ivtv_probe(struct pci_dev *pdev,
itv->tuner_std = itv->std;
if (itv->v4l2_cap & V4L2_CAP_VIDEO_OUTPUT) {
+ v4l2_ctrl_handler_init(&itv->hdl_out, 50);
+ itv->ctrl_pts = v4l2_ctrl_new_std(&itv->hdl_out,
&ivtv_hdl_out_ops,
+ V4L2_CID_MPEG_STREAM_DEC_PTS, 0, 0, 1, 0);
+ itv->ctrl_frame = v4l2_ctrl_new_std(&itv->hdl_out,
&ivtv_hdl_out_ops,
+ V4L2_CID_MPEG_VIDEO_DEC_FRAME, 0, 0x7fff,
1, 0);
+ /* Note: V4L2_MPEG_AUDIO_DEC_PLAYBACK_AUTO is not supported,
+
[RFCv2 PATCH 10/12] av7110: replace audio.h, video.h and osd.h by av7110.h.
From: Hans Verkuil
Create a new public header, av7110.h, that contains all the av7110
specific audio, video and osd APIs that used to be defined in dvb/audio.h,
dvb/video.h and dvb/osd.h. These APIs are no longer part of DVBv5 but are
now av7110-specific.
This decision was taken during the 2011 Prague V4L-DVB workshop.
Ideally av7110 would be converted to use the replacement V4L2 MPEG
decoder API, but that's a huge job for such an old driver.
Signed-off-by: Hans Verkuil
---
drivers/media/dvb/ttpci/av7110.h |4 +-
include/linux/Kbuild |1 +
include/linux/av7110.h | 609 ++
3 files changed, 611 insertions(+), 3 deletions(-)
create mode 100644 include/linux/av7110.h
diff --git a/drivers/media/dvb/ttpci/av7110.h b/drivers/media/dvb/ttpci/av7110.h
index d85b851..e36d6bd 100644
--- a/drivers/media/dvb/ttpci/av7110.h
+++ b/drivers/media/dvb/ttpci/av7110.h
@@ -7,11 +7,9 @@
#include
#include
-#include
-#include
+#include
#include
#include
-#include
#include
#include
diff --git a/include/linux/Kbuild b/include/linux/Kbuild
index 619b565..51bd25f 100644
--- a/include/linux/Kbuild
+++ b/include/linux/Kbuild
@@ -68,6 +68,7 @@ header-y += audit.h
header-y += auto_fs.h
header-y += auto_fs4.h
header-y += auxvec.h
+header-y += av7110.h
header-y += ax25.h
header-y += b1lli.h
header-y += baycom.h
diff --git a/include/linux/av7110.h b/include/linux/av7110.h
new file mode 100644
index 000..a192480
--- /dev/null
+++ b/include/linux/av7110.h
@@ -0,0 +1,609 @@
+/*
+ * av7110.h
+ *
+ * Copyright (C) 2000 Marcus Metzler
+ * & Ralph Metzler
+ *for convergence integrated media GmbH
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public License
+ * as published by the Free Software Foundation; either version 2.1
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ */
+
+#ifndef _AV7110_API_H_
+#define _AV7110_API_H_
+
+#include
+#ifdef __KERNEL__
+#include
+#else
+#include
+#include
+#endif
+
+
+/* av7110 video ioctls
+ *
+ * The DVB video device controls the MPEG2 video decoder of the av7110 DVB
+ * hardware. It can be accessed through /dev/dvb/adapter0/video0.
+ *
+ * Note that the DVB video device only controls decoding of the MPEG video
+ * stream, not its presentation on the TV or computer screen. On PCs this
+ * is typically handled by an associated video4linux device, e.g. /dev/video,
+ * which allows scaling and defining output windows.
+ *
+ * Only one user can open the Video Device in O_RDWR mode. All other attempts
+ * to open the device in this mode will fail and an error code will be
returned.
+ * If the Video Device is opened in O_RDONLY mode, the only ioctl call that can
+ * be used is VIDEO_GET_STATUS. All other calls will return with an error code.
+ *
+ * The write() system call can only be used if VIDEO_SOURCE_MEMORY is selected
+ * in the ioctl call VIDEO_SELECT_SOURCE. The data provided shall be in PES
+ * format. If O_NONBLOCK is not specified the function will block until buffer
+ * space is available. The amount of data to be transferred is implied by
count.
+ */
+
+/** video_format_t
+ * Used in the VIDEO_SET_FORMAT ioctl to tell the driver which aspect ratio
+ * the output hardware (e.g. TV) has. It is also used in the data structures
+ * video_status returned by VIDEO_GET_STATUS and video_event returned by
+ * VIDEO_GET_EVENT which report about the display format of the current video
+ * stream.
+ */
+typedef enum {
+ VIDEO_FORMAT_4_3, /* Select 4:3 format */
+ VIDEO_FORMAT_16_9,/* Select 16:9 format. */
+ VIDEO_FORMAT_221_1/* 2.21:1 */
+} video_format_t;
+
+
+/** video_displayformat_t
+ * In case the display format of the video stream and of the display hardware
+ * differ the application has to specify how to handle the cropping of the
+ * picture. This can be done using the VIDEO_SET_DISPLAY_FORMAT call.
+ */
+typedef enum {
+ VIDEO_PAN_SCAN, /* use pan and scan format */
+ VIDEO_LETTER_BOX, /* use letterbox format */
+ VIDEO_CENTER_CUT_OUT /* use center cut out format */
+} video_displayformat_t;
+
+typedef struct {
+ int w;
+ int h;
+ video_format_t aspect_ratio;
+} video_size_t;
+
+/** video_stream_source_t
+ * The video stream source is set through the VIDEO_SELECT_SOURCE call and
+ * can take the following values, dep
[RFCv2 PATCH 04/12] v4l2-ctrls: add new controls for MPEG decoder devices.
From: Hans Verkuil
As discussed during the 2011 V4L-DVB workshop we want to create a proper V4L2
decoder API that replaces the DVBv5 API that has been used until now.
This adds the four controls necessary to achieve switch ivtv over to this new
API.
Signed-off-by: Hans Verkuil
---
drivers/media/video/v4l2-ctrls.c | 23 +++
include/linux/videodev2.h| 13 +
2 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 0f415da..7051e27 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -175,6 +175,15 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
"16-bit CRC",
NULL
};
+ static const char * const mpeg_audio_dec_playback[] = {
+ "Auto",
+ "Stereo",
+ "Left",
+ "Right",
+ "Mono",
+ "Swapped Stereo",
+ NULL
+ };
static const char * const mpeg_video_encoding[] = {
"MPEG-1",
"MPEG-2",
@@ -374,6 +383,9 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return mpeg_audio_emphasis;
case V4L2_CID_MPEG_AUDIO_CRC:
return mpeg_audio_crc;
+ case V4L2_CID_MPEG_AUDIO_DEC_PLAYBACK:
+ case V4L2_CID_MPEG_AUDIO_DEC_MULTILINGUAL_PLAYBACK:
+ return mpeg_audio_dec_playback;
case V4L2_CID_MPEG_VIDEO_ENCODING:
return mpeg_video_encoding;
case V4L2_CID_MPEG_VIDEO_ASPECT:
@@ -479,6 +491,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_MPEG_STREAM_PES_ID_AUDIO: return "Stream PES Audio ID";
case V4L2_CID_MPEG_STREAM_PES_ID_VIDEO: return "Stream PES Video ID";
case V4L2_CID_MPEG_STREAM_VBI_FMT: return "Stream VBI Format";
+ case V4L2_CID_MPEG_STREAM_DEC_PTS: return "Decoder PTS";
case V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ: return "Audio Sampling
Frequency";
case V4L2_CID_MPEG_AUDIO_ENCODING: return "Audio Encoding";
case V4L2_CID_MPEG_AUDIO_L1_BITRATE:return "Audio Layer I Bitrate";
@@ -491,6 +504,8 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_MPEG_AUDIO_MUTE: return "Audio Mute";
case V4L2_CID_MPEG_AUDIO_AAC_BITRATE: return "Audio AAC Bitrate";
case V4L2_CID_MPEG_AUDIO_AC3_BITRATE: return "Audio AC-3 Bitrate";
+ case V4L2_CID_MPEG_AUDIO_DEC_PLAYBACK: return "Audio Playback";
+ case V4L2_CID_MPEG_AUDIO_DEC_MULTILINGUAL_PLAYBACK: return "Audio
Multilingual Playback";
case V4L2_CID_MPEG_VIDEO_ENCODING: return "Video Encoding";
case V4L2_CID_MPEG_VIDEO_ASPECT:return "Video Aspect";
case V4L2_CID_MPEG_VIDEO_B_FRAMES: return "Video B Frames";
@@ -545,6 +560,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_MPEG_VIDEO_MULTI_SLICE_MAX_MB:return "The
Number of MB in a Slice";
case V4L2_CID_MPEG_VIDEO_MULTI_SLICE_MODE: return "The
Slice Partitioning Method";
case V4L2_CID_MPEG_VIDEO_VBV_SIZE: return "VBV
Buffer Size";
+ case V4L2_CID_MPEG_VIDEO_DEC_FRAME: return "Decoder
Frame Count";
/* CAMERA controls */
/* Keep the order of the 'case's the same as in videodev2.h! */
@@ -673,6 +689,8 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_MPEG_AUDIO_MODE_EXTENSION:
case V4L2_CID_MPEG_AUDIO_EMPHASIS:
case V4L2_CID_MPEG_AUDIO_CRC:
+ case V4L2_CID_MPEG_AUDIO_DEC_PLAYBACK:
+ case V4L2_CID_MPEG_AUDIO_DEC_MULTILINGUAL_PLAYBACK:
case V4L2_CID_MPEG_VIDEO_ENCODING:
case V4L2_CID_MPEG_VIDEO_ASPECT:
case V4L2_CID_MPEG_VIDEO_BITRATE_MODE:
@@ -723,6 +741,11 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
*type = V4L2_CTRL_TYPE_INTEGER;
*flags |= V4L2_CTRL_FLAG_READ_ONLY;
break;
+ case V4L2_CID_MPEG_VIDEO_DEC_FRAME:
+ case V4L2_CID_MPEG_STREAM_DEC_PTS:
+ *type = V4L2_CTRL_TYPE_INTEGER64;
+ *flags |= V4L2_CTRL_FLAG_READ_ONLY | V4L2_CTRL_FLAG_VOLATILE;
+ break;
default:
*type = V4L2_CTRL_TYPE_INTEGER;
break;
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 406f7f7..99f9d5f 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1234,6 +1234,7 @@ enum v4l2_mpeg_stream_vbi_fmt {
V4L2_MPEG_STREAM_VBI_FMT_NONE = 0, /* No VBI in the MPEG stream */
V4L2_MPEG_STREAM_VBI_FMT_IVTV = 1, /* VBI in private packets, IVTV
format */
};
+#define V4L2_CID_MPEG_STREAM_DEC_PTS (V4L2_CID_MPEG_BASE+8)
/* MPEG audio controls specific to multiplexed streams */
#define V4L2_CID_MPEG_AUDIO_SAMPLI
Remove audio and video DVBv5 API
During the 2011 workshop we discussed replacing the decoder commands in include/linux/dvb/video.h and audio.h by a proper V4L2 API. This patch series does that. It adds new VIDIOC_(TRY_)DECODER_CMD ioctls to the V4L2 API. These are identical to the VIDEO_(TRY_)COMMAND from dvb/video.h, but the names of the fields and defines now conform to the V4L2 API conventions. Also new controls are added to replace the remaining functionality needed by ivtv. The new API has been documented. The ivtv.h header has been extended with the 'old' DVB API, making ivtv independent from the old headers. A new av7110.h header has been created that does the same for the av7110.h driver. All the existing relevant DocBook documentation regarding those DVB audio and video APIs has been copied as comments to the av7110.h header. As a final step the old headers and documentation have been removed. Feedback is welcome. 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
[RFCv2 PATCH 02/12] v4l spec: document VIDIOC_(TRY_)DECODER_CMD.
From: Hans Verkuil Signed-off-by: Hans Verkuil --- Documentation/DocBook/media/v4l/v4l2.xml |1 + .../DocBook/media/v4l/vidioc-decoder-cmd.xml | 256 .../DocBook/media/v4l/vidioc-encoder-cmd.xml |9 +- 3 files changed, 262 insertions(+), 4 deletions(-) create mode 100644 Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml index 2ab365c..7fc11db 100644 --- a/Documentation/DocBook/media/v4l/v4l2.xml +++ b/Documentation/DocBook/media/v4l/v4l2.xml @@ -473,6 +473,7 @@ and discussions on the V4L mailing list. &sub-cropcap; &sub-dbg-g-chip-ident; &sub-dbg-g-register; +&sub-decoder-cmd; &sub-dqevent; &sub-encoder-cmd; &sub-enumaudio; diff --git a/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml b/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml new file mode 100644 index 000..466fe27 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml @@ -0,0 +1,256 @@ + + +ioctl VIDIOC_DECODER_CMD, VIDIOC_TRY_DECODER_CMD +&manvol; + + + +VIDIOC_DECODER_CMD +VIDIOC_TRY_DECODER_CMD +Execute an decoder command + + + + + + int ioctl + int fd + int request + struct v4l2_decoder_cmd *argp + + + + + +Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_DECODER_CMD, VIDIOC_TRY_DECODER_CMD + + + + argp + + + + + + + + +Description + + + Experimental + + This is an experimental +interface and may change in the future. + + +These ioctls control an audio/video (usually MPEG-) decoder. +VIDIOC_DECODER_CMD sends a command to the +decoder, VIDIOC_TRY_DECODER_CMD can be used to +try a command without actually executing it. To send a command applications +must initialize all fields of a &v4l2-decoder-cmd; and call +VIDIOC_DECODER_CMD or VIDIOC_TRY_DECODER_CMD +with a pointer to this structure. + +The cmd field must contain the +command code. Some commands use the flags field for +additional information. + + +A write() or &VIDIOC-STREAMON; call sends an implicit +START command to the decoder if it has not been started yet. + + +A close() or &VIDIOC-STREAMOFF; call of a streaming +file descriptor sends an implicit immediate STOP command to the decoder, and all +buffered data is discarded. + +These ioctls are optional, not all drivers may support +them. They were introduced in Linux 3.3. + + + struct v4l2_decoder_cmd + + &cs-str; + + + __u32 + cmd + + + The decoder command, see . + + + __u32 + flags + + + Flags to go with the command. If no flags are defined for +this command, drivers and applications must set this field to zero. + + + union + (anonymous) + + + + + + + struct +start + +Structure containing additional data for the +V4L2_DEC_CMD_START command. + + + + + __u32 + speed +Playback speed and direction. The playback speed is defined as +speed/1000 of the normal speed. So 1000 is normal playback. +Negative numbers denote reverse playback, so -1000 does reverse playback at normal +speed. Speeds -1, 0 and 1 have special meanings: speed 0 is shorthand for 1000 +(normal playback). A speed of 1 steps just one frame forward, a speed of -1 steps +just one frame back. + + + + + + __u32 + format +Format restrictions. This field is set by the driver, not the +application. Possible values are V4L2_DEC_START_FMT_NONE if +there are no format restrictions or V4L2_DEC_START_FMT_GOP +if the decoder operates on full GOPs (Group Of Pictures). +This is usually the case for reverse playback: the decoder needs full GOPs, which +it can then play in reverse order. So to implement reverse playback the application +must feed the decoder the last GOP in the video file, then the GOP before that, etc. etc. + + + + + struct +stop + +Structure containing additional data for the +V4L2_DEC_CMD_STOP command. + + + + + __u64 + pts +Stop playback at this pts or immediately +if the playback is already past that timestamp. Leave to 0 if you want to stop after the +last frame was decoded. + + + + + struct +
[RFCv2 PATCH 01/12] v4l2: add VIDIOC_(TRY_)DECODER_CMD.
From: Hans Verkuil
As discussed during the 2011 V4L-DVB workshop, the API in dvb/video.h should
be replaced by a proper V4L2 API. This patch turns the VIDEO_(TRY_)DECODER_CMD
ioctls into proper V4L2 ioctls.
Signed-off-by: Hans Verkuil
---
drivers/media/video/v4l2-compat-ioctl32.c |2 +
drivers/media/video/v4l2-ioctl.c | 28 +++
include/linux/videodev2.h | 53 +
include/media/v4l2-ioctl.h|4 ++
4 files changed, 87 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-compat-ioctl32.c
b/drivers/media/video/v4l2-compat-ioctl32.c
index c68531b..ffd9b1e 100644
--- a/drivers/media/video/v4l2-compat-ioctl32.c
+++ b/drivers/media/video/v4l2-compat-ioctl32.c
@@ -1003,6 +1003,8 @@ long v4l2_compat_ioctl32(struct file *file, unsigned int
cmd, unsigned long arg)
case VIDIOC_G_ENC_INDEX:
case VIDIOC_ENCODER_CMD:
case VIDIOC_TRY_ENCODER_CMD:
+ case VIDIOC_DECODER_CMD:
+ case VIDIOC_TRY_DECODER_CMD:
case VIDIOC_DBG_S_REGISTER:
case VIDIOC_DBG_G_REGISTER:
case VIDIOC_DBG_G_CHIP_IDENT:
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index e1da8fc..2355510 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -258,6 +258,8 @@ static const char *v4l2_ioctls[] = {
[_IOC_NR(VIDIOC_ENCODER_CMD)] = "VIDIOC_ENCODER_CMD",
[_IOC_NR(VIDIOC_TRY_ENCODER_CMD)] = "VIDIOC_TRY_ENCODER_CMD",
+ [_IOC_NR(VIDIOC_DECODER_CMD)] = "VIDIOC_DECODER_CMD",
+ [_IOC_NR(VIDIOC_TRY_DECODER_CMD)] = "VIDIOC_TRY_DECODER_CMD",
[_IOC_NR(VIDIOC_DBG_S_REGISTER)] = "VIDIOC_DBG_S_REGISTER",
[_IOC_NR(VIDIOC_DBG_G_REGISTER)] = "VIDIOC_DBG_G_REGISTER",
@@ -1658,6 +1660,32 @@ static long __video_do_ioctl(struct file *file,
dbgarg(cmd, "cmd=%d, flags=%x\n", p->cmd, p->flags);
break;
}
+ case VIDIOC_DECODER_CMD:
+ {
+ struct v4l2_decoder_cmd *p = arg;
+
+ if (!ops->vidioc_decoder_cmd)
+ break;
+ if (ret_prio) {
+ ret = ret_prio;
+ break;
+ }
+ ret = ops->vidioc_decoder_cmd(file, fh, p);
+ if (!ret)
+ dbgarg(cmd, "cmd=%d, flags=%x\n", p->cmd, p->flags);
+ break;
+ }
+ case VIDIOC_TRY_DECODER_CMD:
+ {
+ struct v4l2_decoder_cmd *p = arg;
+
+ if (!ops->vidioc_try_decoder_cmd)
+ break;
+ ret = ops->vidioc_try_decoder_cmd(file, fh, p);
+ if (!ret)
+ dbgarg(cmd, "cmd=%d, flags=%x\n", p->cmd, p->flags);
+ break;
+ }
case VIDIOC_G_PARM:
{
struct v4l2_streamparm *p = arg;
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 4b752d5..406f7f7 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1849,6 +1849,54 @@ struct v4l2_encoder_cmd {
};
};
+/* Decoder commands */
+#define V4L2_DEC_CMD_START (0)
+#define V4L2_DEC_CMD_STOP(1)
+#define V4L2_DEC_CMD_PAUSE (2)
+#define V4L2_DEC_CMD_RESUME (3)
+
+/* Flags for V4L2_DEC_CMD_START */
+#define V4L2_DEC_CMD_START_MUTE_AUDIO (1 << 0)
+
+/* Flags for V4L2_DEC_CMD_PAUSE */
+#define V4L2_DEC_CMD_PAUSE_TO_BLACK(1 << 0)
+
+/* Flags for V4L2_DEC_CMD_STOP */
+#define V4L2_DEC_CMD_STOP_TO_BLACK (1 << 0)
+#define V4L2_DEC_CMD_STOP_IMMEDIATELY (1 << 1)
+
+/* Play format requirements (returned by the driver): */
+
+/* The decoder has no special format requirements */
+#define V4L2_DEC_START_FMT_NONE(0)
+/* The decoder requires full GOPs */
+#define V4L2_DEC_START_FMT_GOP (1)
+
+/* The structure must be zeroed before use by the application
+ This ensures it can be extended safely in the future. */
+struct v4l2_decoder_cmd {
+ __u32 cmd;
+ __u32 flags;
+ union {
+ struct {
+ __u64 pts;
+ } stop;
+
+ struct {
+ /* 0 or 1000 specifies normal speed,
+ 1 specifies forward single stepping,
+ -1 specifies backward single stepping,
+ >1: playback at speed/1000 of the normal speed,
+ <-1: reverse playback at (-speed/1000) of the normal
speed. */
+ __s32 speed;
+ __u32 format;
+ } start;
+
+ struct {
+ __u32 data[16];
+ } raw;
+ };
+};
#endif
@@ -2255,6 +2303,11 @@ struct v4l2_create_buffers {
#define VIDIOC_CREATE_BUFS _IOWR('V', 92, struct v4l2_create_buffers)
#define VIDIOC_PREPARE_BUF _IOWR('V', 93, struct
Re: PULL request for 3.2 (fixes 'n' features)
Em 24-11-2011 07:26, Patrick Boettcher escreveu: > Hi Mauro, > > On Tue, 4 Oct 2011, Patrick Boettcher wrote: > >> Hi Mauro, >> >> if it's not too late for 3.2 could you please pull from >> >> git://linuxtv.org/pb/media_tree.git staging/for_v3.2 >> >> for >> >> [media] dib9090: limit the I2C speed [media] dib8096P: add the reference >> board [media] add the support for DiBcom [media] dib7090: add the reference >> board [media] DiB8000: improve the tuning and the SNR monitoring >> [media] DiBcom: correct warnings >> [media] dib7090: add the reference board TFE7090E >> [media] dib7000p/dib0090: update the driver > > I think this PULL request got lost. (as usual for my pull-requests :( ). Yes, I didn't get your pull request. Now that we're using patchwork, to also track pull requests, it is easy for you to check if the pull request is on my queue. Just take a look at http://patchwork.linuxtv.org. It should be noticed that patchwork relies on the way that git request-pull formats the message: $ git request-pull HEAD^1 . The following changes since commit db9bc660cf4d1a09565f5db2bab9d3b86e3e32a5: [media] ir-rc6-decoder: Support RC6-6A variable length data (2011-11-23 22:23:15 -0200) are available in the git repository at: . staging/for_v3.3 Dan Carpenter (1): [media] V4L: mt9t112: use after free in mt9t112_probe() drivers/media/video/mt9t112.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) It basically seeks for "The following...at: " part of the message. If found, it will add it at its repository, like: http://patchwork.linuxtv.org/patch/8279/ > It was meant for 3.2 and was sent in advance. > > Do you think you will get it in? We can get the fixes, and new board additions for 3.2, but driver updates should go to 3.3. > > regards, > -- > > Patrick Boettcher - 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
ir-sanyo-decoder.c doesn't compile
I get this error when compiling for_v3.3: drivers/media/rc/ir-sanyo-decoder.c:201:16: error: expected declaration specifiers or ‘...’ before string constant drivers/media/rc/ir-sanyo-decoder.c:202:15: error: expected declaration specifiers or ‘...’ before string constant drivers/media/rc/ir-sanyo-decoder.c:203:15: error: expected declaration specifiers or ‘...’ before string constant drivers/media/rc/ir-sanyo-decoder.c:204:20: error: expected declaration specifiers or ‘...’ before string constant There is a include missing. This patch fixes this: diff --git a/drivers/media/rc/ir-sanyo-decoder.c b/drivers/media/rc/ir-sanyo-decoder.c index 1646730..d38fbdd 100644 --- a/drivers/media/rc/ir-sanyo-decoder.c +++ b/drivers/media/rc/ir-sanyo-decoder.c @@ -21,6 +21,7 @@ * Information for this protocol is available at the Sanyo LC7461 datasheet. */ +#include #include #include "rc-core-priv.h" Signed-off-by: Hans Verkuil 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: [PATCH/RFC 1/2] v4l: Add a global color alpha control
On 11/24/2011 01:06 PM, Laurent Pinchart wrote: > On Thursday 24 November 2011 12:49:00 Hans Verkuil wrote: >> On Thursday, November 24, 2011 12:39:54 Sylwester Nawrocki wrote: >>> On 11/24/2011 12:09 PM, Laurent Pinchart wrote: On Thursday 24 November 2011 12:00:45 Hans Verkuil wrote: > On Thursday, November 24, 2011 11:53:16 Sylwester Nawrocki wrote: >> This control is intended for video capture or memory-to-memory >> devices that are capable of setting up the alpha conponent to >> some arbitrary value. >> The V4L2_CID_COLOR_ALPHA control allows to set the alpha channel >> globally to a value in range from 0 to 255. >> >> Signed-off-by: Sylwester Nawrocki >> Signed-off-by: Kyungmin Park >> --- >> >> Documentation/DocBook/media/v4l/controls.xml | 20 >> ++-- .../DocBook/media/v4l/pixfmt-packed-rgb.xml >> >> |7 +-- drivers/media/video/v4l2-ctrls.c | >> >> 7 +++ include/linux/videodev2.h |6 >> +++--- 4 files changed, 29 insertions(+), 11 deletions(-) >> >> diff --git a/Documentation/DocBook/media/v4l/controls.xml >> b/Documentation/DocBook/media/v4l/controls.xml index 3bc5ee8..7f99222 >> 100644 >> --- a/Documentation/DocBook/media/v4l/controls.xml >> +++ b/Documentation/DocBook/media/v4l/controls.xml >> @@ -324,12 +324,6 @@ minimum value disables backlight >> compensation. >> >> (usually a microscope). >> >> >> >> >> -V4L2_CID_LASTP1 >> - >> -End of the predefined control IDs (currently >> -V4L2_CID_ILLUMINATORS_2 + 1). >> - >> - >> >> >> V4L2_CID_MIN_BUFFERS_FOR_CAPTURE> ntry >> >> > integer >> >> This is a read-only control that can be read by the >> application >> >> @@ -345,6 +339,20 @@ and used as a hint to determine the number of >> OUTPUT buffers to pass to REQBUFS. >> >> The value is the minimum number of OUTPUT buffers that is necessary >> for hardware to work. >> >> >> >> + >> +V4L2_CID_COLOR_ALPHA >> +integer >> + Sets the color alpha component on the capture >> device. >> It is + applicable to any pixel formats that contain the alpha >> component, + e.g. packed RGB image >> formats. + As the alpha value is global, isn't it applicable to formats with no alpha component as well ? >>> >>> Hmm, I can't say no.. The control was intended as a means of setting up >>> the alpha value for packed RGB formats: >>> http://linuxtv.org/downloads/v4l-dvb-apis/packed-rgb.html#rgb-formats >>> >>> However it could well be used for formats with no alpha. Do you think >>> the second sentence above should be removed or should something else be >>> added to indicate it doesn't necessarily have to have a connection >>> with ARGB color formats ? > > I think we should make it explicit that this global alpha value is applied in > addition to a possibly per-pixel alpha value (if available in the selected > format). I'm not sure if it was the intention. If pixel format has alpha component this control would set per-pixel alpha to an arbitrary control value. If the pixel format doesn't have alpha, then what this control would do - I'm not sure. > >> Huh? How can this be used for formats without an alpha channel? > > If my understanding is correct, this control sets a global alpha value for > the > whole overlay. For instance, with V4L2_CID_COLOR_ALPHA set to 0.5, an overlay More precisely it sets a per-pixel alpha to some arbitrary value. For instance in this case the A value for each pixel with ARGB pixel format would be 128. > using a non-alpha format (such as YUYV), or an overlay using an alpha format > with the alpha value set to 1 for every pixel, would be half transparent. > > In other words, the resulting alpha value is the product of the global alpha > value and the per-pixel alpha value. Non-alpha formats have an implicit per- > pixel alpha value equal to 1 for every pixel. > >> + >> + >> +V4L2_CID_LASTP1 >> + >> +End of the predefined control IDs (currently >> + V4L2_CID_COLOR_ALPHA + 1). >> + >> >> >> >> V4L2_CID_PRIVATE_BASE >> >> >> diff --git a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml >> b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml index >> 4db272b..da4c360 100644 >> --- a/Documentation/DocBook/media/v4l/pixfmt-packed
Re: [PATCH/RFC 1/2] v4l: Add a global color alpha control
On Thursday, November 24, 2011 13:06:09 Laurent Pinchart wrote: > Hi Hans, > > On Thursday 24 November 2011 12:49:00 Hans Verkuil wrote: > > On Thursday, November 24, 2011 12:39:54 Sylwester Nawrocki wrote: > > > On 11/24/2011 12:09 PM, Laurent Pinchart wrote: > > > > On Thursday 24 November 2011 12:00:45 Hans Verkuil wrote: > > > >> On Thursday, November 24, 2011 11:53:16 Sylwester Nawrocki wrote: > > > >>> This control is intended for video capture or memory-to-memory > > > >>> devices that are capable of setting up the alpha conponent to > > > >>> some arbitrary value. > > > >>> The V4L2_CID_COLOR_ALPHA control allows to set the alpha channel > > > >>> globally to a value in range from 0 to 255. > > > >>> > > > >>> Signed-off-by: Sylwester Nawrocki > > > >>> Signed-off-by: Kyungmin Park > > > >>> --- > > > >>> > > > >>> Documentation/DocBook/media/v4l/controls.xml | 20 > > > >>> ++-- .../DocBook/media/v4l/pixfmt-packed-rgb.xml > > > >>> > > > >>> |7 +-- drivers/media/video/v4l2-ctrls.c | > > > >>> > > > >>> 7 +++ include/linux/videodev2.h |6 > > > >>> +++--- 4 files changed, 29 insertions(+), 11 deletions(-) > > > >>> > > > >>> diff --git a/Documentation/DocBook/media/v4l/controls.xml > > > >>> b/Documentation/DocBook/media/v4l/controls.xml index 3bc5ee8..7f99222 > > > >>> 100644 > > > >>> --- a/Documentation/DocBook/media/v4l/controls.xml > > > >>> +++ b/Documentation/DocBook/media/v4l/controls.xml > > > >>> @@ -324,12 +324,6 @@ minimum value disables backlight > > > >>> compensation. > > > >>> > > > >>> (usually a microscope). > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> - V4L2_CID_LASTP1 > > > >>> - > > > >>> - End of the predefined control IDs (currently > > > >>> -V4L2_CID_ILLUMINATORS_2 + 1). > > > >>> - > > > >>> - > > > >>> > > > >>> > > > >>> V4L2_CID_MIN_BUFFERS_FOR_CAPTURE > > >>> ntry > > > >>> > > > >>> > integer > > > >>> > > > >>> This is a read-only control that can be read by the > > > >>> application > > > >>> > > > >>> @@ -345,6 +339,20 @@ and used as a hint to determine the number of > > > >>> OUTPUT buffers to pass to REQBUFS. > > > >>> > > > >>> The value is the minimum number of OUTPUT buffers that is necessary > > > >>> for hardware to work. > > > >>> > > > >>> > > > >>> > > > >>> + > > > >>> + V4L2_CID_COLOR_ALPHA > > > >>> + integer > > > >>> + Sets the color alpha component on the capture > > > >>> device. > > > >>> It is + applicable to any pixel formats that contain the > > > >>> alpha > > > >>> component, + e.g. packed RGB image > > > >>> formats. + > > > > > > > > As the alpha value is global, isn't it applicable to formats with no > > > > alpha component as well ? > > > > > > Hmm, I can't say no.. The control was intended as a means of setting up > > > the alpha value for packed RGB formats: > > > http://linuxtv.org/downloads/v4l-dvb-apis/packed-rgb.html#rgb-formats > > > > > > However it could well be used for formats with no alpha. Do you think > > > the second sentence above should be removed or should something else be > > > added to indicate it doesn't necessarily have to have a connection > > > with ARGB color formats ? > > I think we should make it explicit that this global alpha value is applied in > addition to a possibly per-pixel alpha value (if available in the selected > format). > > > Huh? How can this be used for formats without an alpha channel? > > If my understanding is correct, this control sets a global alpha value for > the > whole overlay. For instance, with V4L2_CID_COLOR_ALPHA set to 0.5, an overlay > using a non-alpha format (such as YUYV), or an overlay using an alpha format > with the alpha value set to 1 for every pixel, would be half transparent. > > In other words, the resulting alpha value is the product of the global alpha > value and the per-pixel alpha value. Non-alpha formats have an implicit per- > pixel alpha value equal to 1 for every pixel. Well, if that's the case, then we already have an API for that (http://hverkuil.home.xs4all.nl/spec/media.html#v4l2-window, field global_alpha). It was my understanding that this is used with a mem2mem device where you just want to fill in the alpha channel to the desired value. It's not used inside the device at all (that happens later in the pipeline). Regards, Hans > > > >>> + > > > >>> + > > > >>> + V4L2_CID_LASTP1 > > > >>> + > > > >>> + End of the predefined control IDs (currently > > > >>> + V4L2_CID_COLOR_ALPHA + 1). > > > >>> + > > > >>> > > > >>> > > > >>> > > > >>> V4L2_CID_PRIVATE_BASE > > > >>> > > > >>> > > > >>> diff --git a/D
Re: [PATCH/RFC 1/2] v4l: Add a global color alpha control
Hi Hans, On Thursday 24 November 2011 12:49:00 Hans Verkuil wrote: > On Thursday, November 24, 2011 12:39:54 Sylwester Nawrocki wrote: > > On 11/24/2011 12:09 PM, Laurent Pinchart wrote: > > > On Thursday 24 November 2011 12:00:45 Hans Verkuil wrote: > > >> On Thursday, November 24, 2011 11:53:16 Sylwester Nawrocki wrote: > > >>> This control is intended for video capture or memory-to-memory > > >>> devices that are capable of setting up the alpha conponent to > > >>> some arbitrary value. > > >>> The V4L2_CID_COLOR_ALPHA control allows to set the alpha channel > > >>> globally to a value in range from 0 to 255. > > >>> > > >>> Signed-off-by: Sylwester Nawrocki > > >>> Signed-off-by: Kyungmin Park > > >>> --- > > >>> > > >>> Documentation/DocBook/media/v4l/controls.xml | 20 > > >>> ++-- .../DocBook/media/v4l/pixfmt-packed-rgb.xml > > >>> > > >>> |7 +-- drivers/media/video/v4l2-ctrls.c | > > >>> > > >>> 7 +++ include/linux/videodev2.h |6 > > >>> +++--- 4 files changed, 29 insertions(+), 11 deletions(-) > > >>> > > >>> diff --git a/Documentation/DocBook/media/v4l/controls.xml > > >>> b/Documentation/DocBook/media/v4l/controls.xml index 3bc5ee8..7f99222 > > >>> 100644 > > >>> --- a/Documentation/DocBook/media/v4l/controls.xml > > >>> +++ b/Documentation/DocBook/media/v4l/controls.xml > > >>> @@ -324,12 +324,6 @@ minimum value disables backlight > > >>> compensation. > > >>> > > >>> (usually a microscope). > > >>> > > >>> > > >>> > > >>> > > >>> - V4L2_CID_LASTP1 > > >>> - > > >>> - End of the predefined control IDs (currently > > >>> -V4L2_CID_ILLUMINATORS_2 + 1). > > >>> - > > >>> - > > >>> > > >>> > > >>> V4L2_CID_MIN_BUFFERS_FOR_CAPTURE > >>> ntry > > >>> > > >>> > integer > > >>> > > >>> This is a read-only control that can be read by the > > >>> application > > >>> > > >>> @@ -345,6 +339,20 @@ and used as a hint to determine the number of > > >>> OUTPUT buffers to pass to REQBUFS. > > >>> > > >>> The value is the minimum number of OUTPUT buffers that is necessary > > >>> for hardware to work. > > >>> > > >>> > > >>> > > >>> + > > >>> + V4L2_CID_COLOR_ALPHA > > >>> + integer > > >>> +Sets the color alpha component on the capture > > >>> device. > > >>> It is + applicable to any pixel formats that contain the alpha > > >>> component, +e.g. packed RGB image > > >>> formats. + > > > > > > As the alpha value is global, isn't it applicable to formats with no > > > alpha component as well ? > > > > Hmm, I can't say no.. The control was intended as a means of setting up > > the alpha value for packed RGB formats: > > http://linuxtv.org/downloads/v4l-dvb-apis/packed-rgb.html#rgb-formats > > > > However it could well be used for formats with no alpha. Do you think > > the second sentence above should be removed or should something else be > > added to indicate it doesn't necessarily have to have a connection > > with ARGB color formats ? I think we should make it explicit that this global alpha value is applied in addition to a possibly per-pixel alpha value (if available in the selected format). > Huh? How can this be used for formats without an alpha channel? If my understanding is correct, this control sets a global alpha value for the whole overlay. For instance, with V4L2_CID_COLOR_ALPHA set to 0.5, an overlay using a non-alpha format (such as YUYV), or an overlay using an alpha format with the alpha value set to 1 for every pixel, would be half transparent. In other words, the resulting alpha value is the product of the global alpha value and the per-pixel alpha value. Non-alpha formats have an implicit per- pixel alpha value equal to 1 for every pixel. > > >>> + > > >>> + > > >>> + V4L2_CID_LASTP1 > > >>> + > > >>> + End of the predefined control IDs (currently > > >>> + V4L2_CID_COLOR_ALPHA + 1). > > >>> + > > >>> > > >>> > > >>> > > >>> V4L2_CID_PRIVATE_BASE > > >>> > > >>> > > >>> diff --git a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml > > >>> b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml index > > >>> 4db272b..da4c360 100644 > > >>> --- a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml > > >>> +++ b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml > > >>> @@ -428,8 +428,11 @@ colorspace > > >>> V4L2_COLORSPACE_SRGB. > > >>> > > >>> Bit 7 is the most significant bit. The value of a = alpha > > >>> > > >>> bits is undefined when reading from the driver, ignored when writing > > >>> to the driver, except when alpha blending has been negotiated for a > > >>> > > >>>
RE: [PATCH] media: vb2: fix queueing of userptr buffers with null buffer pointer
Hello,
On Thursday, November 24, 2011 12:27 PM Laurent Pinchart wrote:
> On Wednesday 16 November 2011 20:22:28 Marek Szyprowski wrote:
> > Heuristic that checks if the memory pointer has been changed lacked a check
> > if the pointer was actually provided by the userspace, what allowed one to
> > queue a NULL pointer which was accepted without further checking.
>
> Is that an issue ? If the pointer is NULL get_user_pages() will fail, won't it
> ?
get_user_pages() fails correctly on NULL pointer, but this patch about something
else. VB2 heuristically checks if the user ptr has been changed compared to
previous
call to QBUF - if so, it releases old buffer and tries to grab a new one with
new
user ptr value.
This heuristic failed if user queued NULL user ptr as a first buffer. All the
buffer
internal structures are zeroed on init, so the comparison of NULL pointer with
initial zero value was true. VB2 incorrectly assumed that it can reuse the
pointer
from the previous QBUF call what caused a kernel ops a few lines later.
>
> > This patch fixes this issue.
> >
> > Reported-by: Sylwester Nawrocki
> > Signed-off-by: Marek Szyprowski
> > Signed-off-by: Kyungmin Park
> > CC: Pawel Osciak
> > ---
> > drivers/media/video/videobuf2-core.c |3 ++-
> > 1 files changed, 2 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/media/video/videobuf2-core.c
> > b/drivers/media/video/videobuf2-core.c index ec49fed..24f11ae 100644
> > --- a/drivers/media/video/videobuf2-core.c
> > +++ b/drivers/media/video/videobuf2-core.c
> > @@ -765,7 +765,8 @@ static int __qbuf_userptr(struct vb2_buffer *vb, struct
> > v4l2_buffer *b)
> >
> > for (plane = 0; plane < vb->num_planes; ++plane) {
> > /* Skip the plane if already verified */
> > - if (vb->v4l2_planes[plane].m.userptr == planes[plane].m.userptr
> > + if (vb->v4l2_planes[plane].m.userptr &&
> > + vb->v4l2_planes[plane].m.userptr == planes[plane].m.userptr
> > && vb->v4l2_planes[plane].length == planes[plane].length)
> > continue;
>
> --
> Regards,
>
> Laurent Pinchart
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
--
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/RFC 1/2] v4l: Add a global color alpha control
On Thursday, November 24, 2011 12:39:54 Sylwester Nawrocki wrote: > Hi Laurent, > > On 11/24/2011 12:09 PM, Laurent Pinchart wrote: > > Hi Sylwester and Hans, > > > > On Thursday 24 November 2011 12:00:45 Hans Verkuil wrote: > >> On Thursday, November 24, 2011 11:53:16 Sylwester Nawrocki wrote: > >>> This control is intended for video capture or memory-to-memory > >>> devices that are capable of setting up the alpha conponent to > >>> some arbitrary value. > >>> The V4L2_CID_COLOR_ALPHA control allows to set the alpha channel > >>> globally to a value in range from 0 to 255. > >>> > >>> Signed-off-by: Sylwester Nawrocki > >>> Signed-off-by: Kyungmin Park > >>> --- > >>> > >>> Documentation/DocBook/media/v4l/controls.xml | 20 > >>> ++-- .../DocBook/media/v4l/pixfmt-packed-rgb.xml > >>> |7 +-- drivers/media/video/v4l2-ctrls.c | > >>> 7 +++ include/linux/videodev2.h |6 > >>> +++--- 4 files changed, 29 insertions(+), 11 deletions(-) > >>> > >>> diff --git a/Documentation/DocBook/media/v4l/controls.xml > >>> b/Documentation/DocBook/media/v4l/controls.xml index 3bc5ee8..7f99222 > >>> 100644 > >>> --- a/Documentation/DocBook/media/v4l/controls.xml > >>> +++ b/Documentation/DocBook/media/v4l/controls.xml > >>> @@ -324,12 +324,6 @@ minimum value disables backlight > >>> compensation. > >>> > >>> (usually a microscope). > >>> > >>> > >>> > >>> > >>> - V4L2_CID_LASTP1 > >>> - > >>> - End of the predefined control IDs (currently > >>> -V4L2_CID_ILLUMINATORS_2 + 1). > >>> - > >>> - > >>> > >>> V4L2_CID_MIN_BUFFERS_FOR_CAPTURE >>> > integer > >>> This is a read-only control that can be read by the > >>> application > >>> > >>> @@ -345,6 +339,20 @@ and used as a hint to determine the number of OUTPUT > >>> buffers to pass to REQBUFS. > >>> > >>> The value is the minimum number of OUTPUT buffers that is necessary for > >>> hardware to work. > >>> > >>> > >>> > >>> + > >>> + V4L2_CID_COLOR_ALPHA > >>> + integer > >>> + Sets the color alpha component on the capture device. It is > >>> + applicable to any pixel formats that contain the alpha component, > >>> + e.g. packed RGB image formats. > >>> + > > > > As the alpha value is global, isn't it applicable to formats with no alpha > > component as well ? > > Hmm, I can't say no.. The control was intended as a means of setting up > the alpha value for packed RGB formats: > http://linuxtv.org/downloads/v4l-dvb-apis/packed-rgb.html#rgb-formats > > However it could well be used for formats with no alpha. Do you think > the second sentence above should be removed or should something else be > added to indicate it doesn't necessarily have to have a connection > with ARGB color formats ? Huh? How can this be used for formats without an alpha channel? > > > > >>> + > >>> + > >>> + V4L2_CID_LASTP1 > >>> + > >>> + End of the predefined control IDs (currently > >>> + V4L2_CID_COLOR_ALPHA + 1). > >>> + > >>> > >>> > >>> > >>> V4L2_CID_PRIVATE_BASE > >>> > >>> > >>> diff --git a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml > >>> b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml index > >>> 4db272b..da4c360 100644 > >>> --- a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml > >>> +++ b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml > >>> @@ -428,8 +428,11 @@ colorspace > >>> V4L2_COLORSPACE_SRGB. > >>> > >>> Bit 7 is the most significant bit. The value of a = alpha > >>> > >>> bits is undefined when reading from the driver, ignored when writing > >>> to the driver, except when alpha blending has been negotiated for a > >>> > >>> -Video Overlay or >>> -linkend="osd">Video Output Overlay. > >>> +Video Overlay or > >>> +Video Output Overlay or when global alpha has been configured > >>> +for a Video Capture by means of > >>> + V4L2_CID_COLOR_ALPHA > >>> + control. > >>> > >>> > >>> > >>>V4L2_PIX_FMT_BGR24 4 × 4 pixel > >>> > >>> diff --git a/drivers/media/video/v4l2-ctrls.c > >>> b/drivers/media/video/v4l2-ctrls.c index 5552f81..bd90955 100644 > >>> --- a/drivers/media/video/v4l2-ctrls.c > >>> +++ b/drivers/media/video/v4l2-ctrls.c > >>> @@ -466,6 +466,7 @@ const char *v4l2_ctrl_get_name(u32 id) > >>> > >>> case V4L2_CID_ILLUMINATORS_2: return "Illuminator 2"; > >>> case V4L2_CID_MIN_BUFFERS_FOR_CAPTURE: return "Minimum Number of > >>> Capture Buffers"; case V4L2_CID_MIN_BUFFERS_FOR_OUTPUT: return > >>> "Minimum Number of Output Buffers"; > >>> > >>> + case V4L2_CID_COLOR_ALPHA: return "Color Alpha"; > >> > >> I prefer CID_ALPHA_COLOR and string "Alpha Color". I think it is more > >> natural than the other way around. > > OK, I guess you're right. And Google returns about twice as many hits for > "alpha color" than for "color alpha"..
Re: [PATCH/RFC 1/2] v4l: Add a global color alpha control
Hi Laurent, On 11/24/2011 12:09 PM, Laurent Pinchart wrote: > Hi Sylwester and Hans, > > On Thursday 24 November 2011 12:00:45 Hans Verkuil wrote: >> On Thursday, November 24, 2011 11:53:16 Sylwester Nawrocki wrote: >>> This control is intended for video capture or memory-to-memory >>> devices that are capable of setting up the alpha conponent to >>> some arbitrary value. >>> The V4L2_CID_COLOR_ALPHA control allows to set the alpha channel >>> globally to a value in range from 0 to 255. >>> >>> Signed-off-by: Sylwester Nawrocki >>> Signed-off-by: Kyungmin Park >>> --- >>> >>> Documentation/DocBook/media/v4l/controls.xml | 20 >>> ++-- .../DocBook/media/v4l/pixfmt-packed-rgb.xml >>> |7 +-- drivers/media/video/v4l2-ctrls.c | >>> 7 +++ include/linux/videodev2.h |6 >>> +++--- 4 files changed, 29 insertions(+), 11 deletions(-) >>> >>> diff --git a/Documentation/DocBook/media/v4l/controls.xml >>> b/Documentation/DocBook/media/v4l/controls.xml index 3bc5ee8..7f99222 >>> 100644 >>> --- a/Documentation/DocBook/media/v4l/controls.xml >>> +++ b/Documentation/DocBook/media/v4l/controls.xml >>> @@ -324,12 +324,6 @@ minimum value disables backlight >>> compensation. >>> >>> (usually a microscope). >>> >>> >>> >>> >>> - V4L2_CID_LASTP1 >>> - >>> - End of the predefined control IDs (currently >>> -V4L2_CID_ILLUMINATORS_2 + 1). >>> - >>> - >>> >>> V4L2_CID_MIN_BUFFERS_FOR_CAPTURE>> > integer >>> This is a read-only control that can be read by the >>> application >>> >>> @@ -345,6 +339,20 @@ and used as a hint to determine the number of OUTPUT >>> buffers to pass to REQBUFS. >>> >>> The value is the minimum number of OUTPUT buffers that is necessary for >>> hardware to work. >>> >>> >>> >>> + >>> + V4L2_CID_COLOR_ALPHA >>> + integer >>> +Sets the color alpha component on the capture device. It is >>> + applicable to any pixel formats that contain the alpha component, >>> + e.g. packed RGB image formats. >>> + > > As the alpha value is global, isn't it applicable to formats with no alpha > component as well ? Hmm, I can't say no.. The control was intended as a means of setting up the alpha value for packed RGB formats: http://linuxtv.org/downloads/v4l-dvb-apis/packed-rgb.html#rgb-formats However it could well be used for formats with no alpha. Do you think the second sentence above should be removed or should something else be added to indicate it doesn't necessarily have to have a connection with ARGB color formats ? > >>> + >>> + >>> + V4L2_CID_LASTP1 >>> + >>> + End of the predefined control IDs (currently >>> + V4L2_CID_COLOR_ALPHA + 1). >>> + >>> >>> >>> >>> V4L2_CID_PRIVATE_BASE >>> >>> >>> diff --git a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml >>> b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml index >>> 4db272b..da4c360 100644 >>> --- a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml >>> +++ b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml >>> @@ -428,8 +428,11 @@ colorspace >>> V4L2_COLORSPACE_SRGB. >>> >>> Bit 7 is the most significant bit. The value of a = alpha >>> >>> bits is undefined when reading from the driver, ignored when writing >>> to the driver, except when alpha blending has been negotiated for a >>> >>> -Video Overlay or >> -linkend="osd">Video Output Overlay. >>> +Video Overlay or >>> +Video Output Overlay or when global alpha has been configured >>> +for a Video Capture by means of >>> + V4L2_CID_COLOR_ALPHA >>> + control. >>> >>> >>> >>>V4L2_PIX_FMT_BGR24 4 × 4 pixel >>> >>> diff --git a/drivers/media/video/v4l2-ctrls.c >>> b/drivers/media/video/v4l2-ctrls.c index 5552f81..bd90955 100644 >>> --- a/drivers/media/video/v4l2-ctrls.c >>> +++ b/drivers/media/video/v4l2-ctrls.c >>> @@ -466,6 +466,7 @@ const char *v4l2_ctrl_get_name(u32 id) >>> >>> case V4L2_CID_ILLUMINATORS_2: return "Illuminator 2"; >>> case V4L2_CID_MIN_BUFFERS_FOR_CAPTURE: return "Minimum Number of >>> Capture Buffers"; case V4L2_CID_MIN_BUFFERS_FOR_OUTPUT: return >>> "Minimum Number of Output Buffers"; >>> >>> + case V4L2_CID_COLOR_ALPHA: return "Color Alpha"; >> >> I prefer CID_ALPHA_COLOR and string "Alpha Color". I think it is more >> natural than the other way around. OK, I guess you're right. And Google returns about twice as many hits for "alpha color" than for "color alpha"... > > I'm not too found of "color" in the name. Is the alpha value considered as a > color ? Certainly it isn't, but Alpha alone looks a bit odd. It's too generic IMHO. > >> Other than that I'm OK with this. >> >> Regards, >> >> Hans -- Thanks, Sylwester -- To unsubscribe from this list: send the line "unsubscr
Re: Using MT9P031 digital sensor
Hi Gary, On Wednesday 16 November 2011 13:03:11 Gary Thomas wrote: > On 2011-11-15 18:26, Laurent Pinchart wrote: > > On Monday 14 November 2011 12:42:54 Gary Thomas wrote: > >> On 2011-11-11 07:26, Laurent Pinchart wrote: > >>> On Wednesday 09 November 2011 17:24:26 Gary Thomas wrote: > On 2011-11-09 09:18, Laurent Pinchart wrote: > > On Wednesday 09 November 2011 12:01:34 Gary Thomas wrote: > >> On 2011-11-08 17:54, Laurent Pinchart wrote: > >>> On Tuesday 08 November 2011 14:38:55 Gary Thomas wrote: > On 2011-11-08 06:06, Laurent Pinchart wrote: > > On Tuesday 08 November 2011 13:52:25 Gary Thomas wrote: > >> On 2011-11-08 05:30, Javier Martinez Canillas wrote: > >>> On Tue, Nov 8, 2011 at 1:20 PM, Gary Thomas wrote: > On 2011-11-04 04:37, Laurent Pinchart wrote: > > On Tuesday 01 November 2011 19:52:49 Gary Thomas wrote: > >> I'm trying to use the MT9P031 digital sensor with the Media > >> Controller Framework. media-ctl tells me that the sensor is > >> set to capture using SGRBG12 2592x1944 > >> > >> Questions: > >> * What pixel format in ffmpeg does this correspond to? > > > > I don't know if ffmpeg supports Bayer formats. The > > corresponding fourcc in V4L2 is BA12. > > ffmpeg doesn't seem to support these formats > > > If your sensor is hooked up to the OMAP3 ISP, you can then > > configure the pipeline to include the preview engine and the > > resizer, and capture YUV data > > at the resizer output. > > I am using the OMAP3 ISP, but it's a bit unclear to me how to > set up the pipeline > >>> > >>> Hi Gary, > >>> > >>> I'm also using another sensor mtv9034 with OMAP3 ISP, so maybe > >>> I can help you. > >>> > using media-ctl (I looked for documentation on this tool, but > came up dry - is there any?) > > Do you have an example of how to configure this using the > OMAP3 ISP? > >>> > >>> This is how I configure the pipeline to connect the CCDC with > >>> the Previewer and Resizer: > >>> > >>> ./media-ctl -l '"mt9v032 3-005c":0->"OMAP3 ISP CCDC":0[1]' > >>> ./media-ctl -l '"OMAP3 ISP CCDC":2->"OMAP3 ISP preview":0[1]' > >>> ./media-ctl -l '"OMAP3 ISP preview":1->"OMAP3 ISP > >>> resizer":0[1]' ./media-ctl -l '"OMAP3 ISP resizer":1->"OMAP3 > >>> ISP resizer output":0[1]' ./media-ctl -f '"mt9v032 > >>> 3-005c":0[SGRBG10 752x480]' ./media-ctl -f '"OMAP3 ISP > >>> CCDC":0 [SGRBG10 752x480]' ./media-ctl -f '"OMAP3 ISP CCDC":1 > >>> [SGRBG10 752x480]' ./media-ctl -f '"OMAP3 ISP preview":0 > >>> [SGRBG10 752x479]' ./media-ctl -f '"OMAP3 ISP resizer":0 > >>> [YUYV 734x471]' ./media-ctl -f '"OMAP3 ISP resizer":1 [YUYV > >>> 640x480]' > >>> > >>> Hope it helps, > >> > >> Thanks, I'll give this a try. > >> > >> I assume that your sensor is probably larger than 752x480 (the > >> mt9p031 is 2592x1944 raw) and that setting the smaller frame > >> size enables some scaling and/or cropping in the driver? > > > > The mt9v034 is a wide VGA 752x480 sensor if I'm not mistaken. You > > should modify the resolutions in the above commands according to > > your sensor. Note that the CCDC crops online line when outputting > > data to the preview engine, and that the preview engine crops 18 > > columsn and 8 lines. You can then scale the image by modifying > > the resizer output size. > > Thanks. After much trial and error (and some kernel printks to > > understand what parameters were failing), I came up with this > > > > sequence: > media-ctl -r > media-ctl -l '"mt9p031 3-005d":0->"OMAP3 ISP CCDC":0[1]' > media-ctl -l '"OMAP3 ISP CCDC":2->"OMAP3 ISP preview":0[1]' > media-ctl -l '"OMAP3 ISP preview":1->"OMAP3 ISP > resizer":0[1]' media-ctl -l '"OMAP3 ISP resizer":1->"OMAP3 > ISP resizer output":0[1]' media-ctl -f '"mt9p031 > 3-005d":0[SGRBG12 2592x1944]' media-ctl -f '"OMAP3 ISP > CCDC":0 [SGRBG12 2592x1944]' > media-ctl -f '"OMAP3 ISP CCDC":1 [SGRBG12 2592x1944]' > media-ctl -f '"OMAP3 ISP preview":0 [SGRBG12 2592x1943]' > media-ctl -f '"OMAP3 ISP resizer":0 [YUYV 2574x1935]' > media-ctl -f '"OMAP3 ISP resizer":1 [YUYV 642x483]' > > When I tried to grab though, I got this: > > # ya
Re: [PATCH] media: vb2: fix queueing of userptr buffers with null buffer pointer
Hi Marek,
On Wednesday 16 November 2011 20:22:28 Marek Szyprowski wrote:
> Heuristic that checks if the memory pointer has been changed lacked a check
> if the pointer was actually provided by the userspace, what allowed one to
> queue a NULL pointer which was accepted without further checking.
Is that an issue ? If the pointer is NULL get_user_pages() will fail, won't it
?
> This patch fixes this issue.
>
> Reported-by: Sylwester Nawrocki
> Signed-off-by: Marek Szyprowski
> Signed-off-by: Kyungmin Park
> CC: Pawel Osciak
> ---
> drivers/media/video/videobuf2-core.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/media/video/videobuf2-core.c
> b/drivers/media/video/videobuf2-core.c index ec49fed..24f11ae 100644
> --- a/drivers/media/video/videobuf2-core.c
> +++ b/drivers/media/video/videobuf2-core.c
> @@ -765,7 +765,8 @@ static int __qbuf_userptr(struct vb2_buffer *vb, struct
> v4l2_buffer *b)
>
> for (plane = 0; plane < vb->num_planes; ++plane) {
> /* Skip the plane if already verified */
> - if (vb->v4l2_planes[plane].m.userptr == planes[plane].m.userptr
> + if (vb->v4l2_planes[plane].m.userptr &&
> + vb->v4l2_planes[plane].m.userptr == planes[plane].m.userptr
> && vb->v4l2_planes[plane].length == planes[plane].length)
> continue;
--
Regards,
Laurent Pinchart
--
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: mt9p031 based sensor and ack lockups. Ie CCDC won't become idle.
Hi Andrew, On Monday 21 November 2011 00:54:04 Andrew Tubbiolo wrote: > Hi All: > >I'm having fun with my new camera project that uses the mt9p031 > camera. I'm getting nice raw stills, and that's great, but every 16 or > so images I take I get a troublesome error. > > CCDC won't become idle! > > The message is coming from... > > > static int ccdc_isr_buffer(struct isp_ccdc_device *ccdc) > > in ... > > linux-2.6.39.1/drivers/media/video/omap3isp/ispccdc.c > > I printed out the return of the status of the registers on the CCDC > and found that the only bit set was the CCDC_BUSY register. [snip] > I THINK I'm suffering from a data underflow, where the previous batch > of images did not complete, or something. The OMAP3 ISP is quite picky about its input signals and doesn't gracefully handle missing or extra sync pulses for instance. A "CCDC won't become idle!" message usually indicates that the CCDC received a frame of unexpected size (this can happen if the sensor stops in the middle of a frame for instance), or that the driver had no time to process the end of frame interrupt before the next frame arrived (either because of an unsually long interrupt delay on the system, or because of too low vertical blanking). > Which is funny because I almost always get a full data set if everything > starts up with no hiccup. I should add that I get this error when I start a > exposure and data ack. The error is immediate, not in the middle of an ack. > In fact the error is thrown during the yavta init sequence. During a > ioctl(STREAM_ON). > > I tried to issue a isp flush to the flush bit as described on (fig > Table 12-88 ISP_CTRL) pg 1512 of the TI-OMAP manual. This froze the > whole system. I'm wondering if anyone else is running into a similar > or even the same problem and if they know of a solution, a fix, or a > workaround? -- Regards, Laurent Pinchart -- 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 v2] Add version number to all siano modules description lines.
Em 03-11-2011 09:34, Doron Cohen escreveu:
>
>
>>From 595a6726947b032ce355ac0d838f07d937ed7f57 Mon Sep 17 00:00:00 2001
> From: Doron Cohen
> Date: Thu, 15 Sep 2011 11:38:53 +0300
> Subject: [PATCH 2/2] Add version number to all siano modules description
> line.
Patch looks ok, but it is also line-wrapped.
>
> Signed-off-by: Doron Cohen
> ---
> drivers/media/dvb/siano/smscoreapi.c |3 ++-
> drivers/media/dvb/siano/smscoreapi.h | 13 +
> drivers/media/dvb/siano/smsdvb.c |3 ++-
> drivers/media/dvb/siano/smssdio.c|3 ++-
> drivers/media/dvb/siano/smsspidrv.c |3 ++-
> drivers/media/dvb/siano/smsusb.c |3 ++-
> 6 files changed, 23 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/dvb/siano/smscoreapi.c
> b/drivers/media/dvb/siano/smscoreapi.c
> index c0acacc..dfbc648 100644
> --- a/drivers/media/dvb/siano/smscoreapi.c
> +++ b/drivers/media/dvb/siano/smscoreapi.c
> @@ -1639,6 +1639,7 @@ static void __exit smscore_module_exit(void)
> module_init(smscore_module_init);
> module_exit(smscore_module_exit);
>
> +MODULE_VERSION(VERSION_STRING);
> MODULE_DESCRIPTION("Siano MDTV Core module");
> -MODULE_AUTHOR("Siano Mobile Silicon, Inc. (u...@siano-ms.com)");
> +MODULE_AUTHOR(MODULE_AUTHOR_STRING);
> MODULE_LICENSE("GPL");
> diff --git a/drivers/media/dvb/siano/smscoreapi.h
> b/drivers/media/dvb/siano/smscoreapi.h
> index bd1cafc..aabcad3 100644
> --- a/drivers/media/dvb/siano/smscoreapi.h
> +++ b/drivers/media/dvb/siano/smscoreapi.h
> @@ -35,6 +35,19 @@ along with this program. If not, see
>
Re: [RFC PATCH 2/4] v4l spec: document VIDIOC_(TRY_)DECODER_CMD.
Hi Hans, Thanks for the patch. On Wednesday 23 November 2011 12:12:34 Hans Verkuil wrote: > From: Hans Verkuil > > Signed-off-by: Hans Verkuil > --- [snip] > diff --git a/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml > b/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml new file mode > 100644 > index 000..bf016f0 > --- /dev/null > +++ b/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml > @@ -0,0 +1,250 @@ > + > + > +ioctl VIDIOC_DECODER_CMD, > VIDIOC_TRY_DECODER_CMD +&manvol; > + > + > + > +VIDIOC_DECODER_CMD > +VIDIOC_TRY_DECODER_CMD > +Execute an decoder command > + > + > + > + > + > + int ioctl > + int fd > + int request > + struct v4l2_decoder_cmd > *argp > + > + > + > + > + > +Arguments > + > + > + > + fd > + > + &fd; > + > + > + > + request > + > + VIDIOC_DECODER_CMD, VIDIOC_TRY_DECODER_CMD > + > + > + > + argp > + > + > + > + > + > + > + > + > +Description > + > + > + Experimental > + > + This is an experimental > +interface and may change in the future. > + > + > +These ioctls control an audio/video (usually MPEG-) decoder. > +VIDIOC_DECODER_CMD sends a command to the > +decoder, VIDIOC_TRY_DECODER_CMD can be used to > +try a command without actually executing it. To send a command > applications +must initialize all fields of a &v4l2-decoder-cmd; and call > +VIDIOC_DECODER_CMD or > VIDIOC_TRY_DECODER_CMD +with a pointer to this > structure. > + > +The cmd field must contain the > +command code. Some commands use the flags field > for +additional information. > + > + > +A write() call sends a START command to > +the decoder if it has not been started yet. > + > + > +A close() call sends an immediate STOP > +to the decoder, and all buffered data is discarded. > + > +These ioctls are optional, not all drivers may support > +them. They were introduced in Linux 3.3. > + > + > + struct v4l2_decoder_cmd > + > + &cs-str; > + > + > + __u32 > + cmd > + > + > + The decoder command, see />. + > + > + __u32 > + flags > + > + > + Flags to go with the command. If no flags are defined for > +this command, drivers and applications must set this field to > zero. + > + > + union > + (anonymous) > + > + > + > + > + > + > + struct > +start > + > +Structure containing additional data for the > +V4L2_DEC_CMD_START command. > + > + > + > + > + __u32 > + speed > +Playback speed and direction. The playback speed is > defined as +speed/1000 of the normal speed. So > 1000 is normal playback. +Negative numbers denote reverse playback, so > -1000 does reverse playback at normal +speed. Speeds -1, 0 and 1 have > special meanings: speed 0 is shorthand for 1000 +(normal playback). A > speed of 1 steps just one frame forward, a speed of -1 steps +just one > frame back. > + > + > + > + > + > + __u32 > + format > +Format restrictions. This field is set by the driver, > not the +application. Possible values are > V4L2_DEC_START_FMT_NONE if +there are no format > restrictions or V4L2_DEC_START_FMT_GOP +if the > decoder operates on full GOPs (Group Of > Pictures). +This is usually the case for reverse playback: > the decoder needs full GOPs, which +it can then play in reverse order. So > to implement reverse playback the application +must feed the decoder the > last GOP in the video file, then the GOP before that, etc. etc. + > > + > + > + > + struct > +stop > + > +Structure containing additional data for the > +V4L2_DEC_CMD_STOP command. > + > + > + > + > + __u64 > + pts > +Stop playback at this pts or > immediately +if the playback is already past that timestamp. Leave to 0 if > you want to stop after the +last frame was decoded. > + > + > + > + > + struct > +raw > + > + > + > + > + > + > + __u32 > + data[16] > + Reserved for future extensions. Drivers and > +applications must set the array to zero. > + > + > + > + > + > + > + Decoder Commands > + > + &cs-def; > + > + > + V4L2_DEC_CMD_START > + 0 > + Start the decoder. When the decoder is already > +running or paused, this command does nothing. There are no flags > +associated wi
Re: [PATCH v2] Add smsspi driver to support Siano SPI connected device
Em 03-11-2011 09:33, Doron Cohen escreveu: > >>From 80d279ec11492ca6729f1421983f52b8e7144cd4 Mon Sep 17 00:00:00 2001 > From: Doron Cohen > Date: Sun, 25 Sep 2011 17:47:12 +0300 > Subject: [PATCH v2] Add smsspi driver to support Siano SPI connected > device > using SPI generic driver > > modified: drivers/media/dvb/siano/smsspidrv.c > modified: drivers/media/dvb/siano/smsspiphy.c > > new file: drivers/media/dvb/siano/smsspidrv.c > new file: drivers/media/dvb/siano/smsspiphy.c > > new file: drivers/media/dvb/siano/smsspidrv.c > new file: drivers/media/dvb/siano/smsspiphy.c > new file: drivers/media/dvb/siano/smsspiphy.h > > modified: drivers/media/dvb/siano/Kconfig > new file: drivers/media/dvb/siano/smsspiphy.c > > Signed-off-by: Doron Cohen > --- > drivers/media/dvb/siano/Kconfig| 23 ++ > drivers/media/dvb/siano/Makefile |2 + > drivers/media/dvb/siano/smscoreapi.c |2 +- > drivers/media/dvb/siano/smsdbg_prn.h | 56 > drivers/media/dvb/siano/smsspicommon.c | 407 > +++ > drivers/media/dvb/siano/smsspicommon.h | 96 +++ > drivers/media/dvb/siano/smsspidrv.c| 472 > Hi Doron, your patch doesn't apply, because your emailer broke long lines and did some other random whitespace wrapping. Please, re-send it. The best way for you to send patches is to use "git send-email". You need to configure your sendmail for it to work with your smarthost, but, once done, it works like a charm. It is also hard to read the code with this broken indentation, due to the line wrapping. I just did a few comments. I'll take a more detailed look after your re-send. Regards, Mauro > drivers/media/dvb/siano/smsspiphy.c| 218 +++ > drivers/media/dvb/siano/smsspiphy.h| 38 +++ > 9 files changed, 1313 insertions(+), 1 deletions(-) > create mode 100644 drivers/media/dvb/siano/smsdbg_prn.h > create mode 100644 drivers/media/dvb/siano/smsspicommon.c > create mode 100644 drivers/media/dvb/siano/smsspicommon.h > create mode 100644 drivers/media/dvb/siano/smsspidrv.c > create mode 100644 drivers/media/dvb/siano/smsspiphy.c > create mode 100644 drivers/media/dvb/siano/smsspiphy.h > > diff --git a/drivers/media/dvb/siano/Kconfig > b/drivers/media/dvb/siano/Kconfig > index bc6456e..a47a131 100644 > --- a/drivers/media/dvb/siano/Kconfig > +++ b/drivers/media/dvb/siano/Kconfig > @@ -17,6 +17,15 @@ config SMS_SIANO_MDTV > if SMS_SIANO_MDTV > menu "Siano module components" > > +# Kernel sub systems support > + > +config SMS_NET_SUBSYS > + tristate "Siano Network Adapter" > + depends on NET > + default n > + ---help--- > + Choose if you would like to have Siano's network adapter > support. > + What the Net Subsys has to do with "Add smsspi driver to support Siano SPI connected"? Please, don't mix different subjects into the same patch, as it makes harder for review, expecially on big patches like this. > # Hardware interfaces support > > config SMS_USB_DRV > @@ -30,5 +39,19 @@ config SMS_SDIO_DRV > depends on DVB_CORE && MMC > ---help--- > Choose if you would like to have Siano's support for SDIO > interface > + > +config SMS_SPI_DRV > + tristate "SPI interface support" > + depends on SPI > + default y if SPI > + ---help--- > + Choose if you would like to have Siano's support for SPI > interface > + > +config SMS_I2C_DRV > + tristate "I2C interface support" > + depends on DVB_CORE && I2C > + ---help--- > + Choose if you would like to have Siano's support for I2C > interface > + > endmenu > endif # SMS_SIANO_MDTV > diff --git a/drivers/media/dvb/siano/Makefile > b/drivers/media/dvb/siano/Makefile > index c54140b..affaf01 100644 > --- a/drivers/media/dvb/siano/Makefile > +++ b/drivers/media/dvb/siano/Makefile > @@ -1,9 +1,11 @@ > > smsmdtv-objs := smscoreapi.o sms-cards.o smsendian.o smsir.o > +smsspi-objs := smsspicommon.o smsspidrv.o smsspiphy.o > > obj-$(CONFIG_SMS_SIANO_MDTV) += smsmdtv.o smsdvb.o > obj-$(CONFIG_SMS_USB_DRV) += smsusb.o > obj-$(CONFIG_SMS_SDIO_DRV) += smssdio.o > +obj-$(CONFIG_SMS_SPI_DRV) += smsspi.o > > EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core > > diff --git a/drivers/media/dvb/siano/smscoreapi.c > b/drivers/media/dvb/siano/smscoreapi.c > index 78765ed..239f453 100644 > --- a/drivers/media/dvb/siano/smscoreapi.c > +++ b/drivers/media/dvb/siano/smscoreapi.c > @@ -39,7 +39,7 @@ > #include "smsir.h" > #include "smsendian.h" > > -static int sms_dbg; > +int sms_dbg; > module_param_named(debug, sms_dbg, int, 0644); > MODULE_PARM_DESC(debug, "set debug level (info=1, adv=2 (or-able))"); > > diff --git a/drivers/media/dvb/siano/smsdbg_prn.h > b/drivers/media/dvb/siano/smsdbg_prn.h > new file mode 100644 > index 000..ea157da > --- /dev/null > +++ b/drivers/media/dvb/siano/smsdbg_prn.h > @@ -0,0 +1,56 @
Re: [PATCH/RFC 1/2] v4l: Add a global color alpha control
Hi Sylwester and Hans, On Thursday 24 November 2011 12:00:45 Hans Verkuil wrote: > On Thursday, November 24, 2011 11:53:16 Sylwester Nawrocki wrote: > > This control is intended for video capture or memory-to-memory > > devices that are capable of setting up the alpha conponent to > > some arbitrary value. > > The V4L2_CID_COLOR_ALPHA control allows to set the alpha channel > > globally to a value in range from 0 to 255. > > > > Signed-off-by: Sylwester Nawrocki > > Signed-off-by: Kyungmin Park > > --- > > > > Documentation/DocBook/media/v4l/controls.xml | 20 > > ++-- .../DocBook/media/v4l/pixfmt-packed-rgb.xml > > |7 +-- drivers/media/video/v4l2-ctrls.c | > > 7 +++ include/linux/videodev2.h |6 > > +++--- 4 files changed, 29 insertions(+), 11 deletions(-) > > > > diff --git a/Documentation/DocBook/media/v4l/controls.xml > > b/Documentation/DocBook/media/v4l/controls.xml index 3bc5ee8..7f99222 > > 100644 > > --- a/Documentation/DocBook/media/v4l/controls.xml > > +++ b/Documentation/DocBook/media/v4l/controls.xml > > @@ -324,12 +324,6 @@ minimum value disables backlight > > compensation. > > > > (usually a microscope). > > > > > > > > > > - V4L2_CID_LASTP1 > > - > > - End of the predefined control IDs (currently > > -V4L2_CID_ILLUMINATORS_2 + 1). > > - > > - > > > > V4L2_CID_MIN_BUFFERS_FOR_CAPTURE > > integer > > This is a read-only control that can be read by the > > application > > > > @@ -345,6 +339,20 @@ and used as a hint to determine the number of OUTPUT > > buffers to pass to REQBUFS. > > > > The value is the minimum number of OUTPUT buffers that is necessary for > > hardware to work. > > > > > > > > + > > + V4L2_CID_COLOR_ALPHA > > + integer > > +Sets the color alpha component on the capture device. It is > > + applicable to any pixel formats that contain the alpha component, > > + e.g. packed RGB image formats. > > + As the alpha value is global, isn't it applicable to formats with no alpha component as well ? > > + > > + > > + V4L2_CID_LASTP1 > > + > > + End of the predefined control IDs (currently > > + V4L2_CID_COLOR_ALPHA + 1). > > + > > > > > > > > V4L2_CID_PRIVATE_BASE > > > > > > diff --git a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml > > b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml index > > 4db272b..da4c360 100644 > > --- a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml > > +++ b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml > > @@ -428,8 +428,11 @@ colorspace > > V4L2_COLORSPACE_SRGB. > > > > Bit 7 is the most significant bit. The value of a = alpha > > > > bits is undefined when reading from the driver, ignored when writing > > to the driver, except when alpha blending has been negotiated for a > > > > -Video Overlay or > -linkend="osd">Video Output Overlay. > > +Video Overlay or > > +Video Output Overlay or when global alpha has been configured > > +for a Video Capture by means of > > + V4L2_CID_COLOR_ALPHA > > + control. > > > > > > > >V4L2_PIX_FMT_BGR24 4 × 4 pixel > > > > diff --git a/drivers/media/video/v4l2-ctrls.c > > b/drivers/media/video/v4l2-ctrls.c index 5552f81..bd90955 100644 > > --- a/drivers/media/video/v4l2-ctrls.c > > +++ b/drivers/media/video/v4l2-ctrls.c > > @@ -466,6 +466,7 @@ const char *v4l2_ctrl_get_name(u32 id) > > > > case V4L2_CID_ILLUMINATORS_2: return "Illuminator 2"; > > case V4L2_CID_MIN_BUFFERS_FOR_CAPTURE: return "Minimum Number of > > Capture Buffers"; case V4L2_CID_MIN_BUFFERS_FOR_OUTPUT: return > > "Minimum Number of Output Buffers"; > > > > + case V4L2_CID_COLOR_ALPHA: return "Color Alpha"; > > I prefer CID_ALPHA_COLOR and string "Alpha Color". I think it is more > natural than the other way around. I'm not too found of "color" in the name. Is the alpha value considered as a color ? > Other than that I'm OK with this. > > Regards, > > Hans > > > /* MPEG controls */ > > /* Keep the order of the 'case's the same as in videodev2.h! */ > > > > @@ -714,6 +715,12 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum > > v4l2_ctrl_type *type, > > > > /* Max is calculated as RGB888 that is 2^24 */ > > *max = 0xFF; > > break; > > > > + case V4L2_CID_COLOR_ALPHA: > > + *type = V4L2_CTRL_TYPE_INTEGER; > > + *step = 1; > > + *min = 0; > > + *max = 0xff; > > + break; > > > > case V4L2_CID_FLASH_FAULT: > > *type = V4L2_CTRL_TYPE_BITMASK; > > break; > > > > diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h > > index 4b752d5..42192c1 100644 > > --- a/inclu
Re: [PATCH/RFC 1/2] v4l: Add a global color alpha control
On Thursday, November 24, 2011 11:53:16 Sylwester Nawrocki wrote:
> This control is intended for video capture or memory-to-memory
> devices that are capable of setting up the alpha conponent to
> some arbitrary value.
> The V4L2_CID_COLOR_ALPHA control allows to set the alpha channel
> globally to a value in range from 0 to 255.
>
> Signed-off-by: Sylwester Nawrocki
> Signed-off-by: Kyungmin Park
> ---
> Documentation/DocBook/media/v4l/controls.xml | 20
> ++--
> .../DocBook/media/v4l/pixfmt-packed-rgb.xml|7 +--
> drivers/media/video/v4l2-ctrls.c |7 +++
> include/linux/videodev2.h |6 +++---
> 4 files changed, 29 insertions(+), 11 deletions(-)
>
> diff --git a/Documentation/DocBook/media/v4l/controls.xml
> b/Documentation/DocBook/media/v4l/controls.xml
> index 3bc5ee8..7f99222 100644
> --- a/Documentation/DocBook/media/v4l/controls.xml
> +++ b/Documentation/DocBook/media/v4l/controls.xml
> @@ -324,12 +324,6 @@ minimum value disables backlight compensation.
> (usually a microscope).
>
>
> - V4L2_CID_LASTP1
> -
> - End of the predefined control IDs (currently
> -V4L2_CID_ILLUMINATORS_2 + 1).
> -
> -
> V4L2_CID_MIN_BUFFERS_FOR_CAPTURE
> integer
> This is a read-only control that can be read by the
> application
> @@ -345,6 +339,20 @@ and used as a hint to determine the number of OUTPUT
> buffers to pass to REQBUFS.
> The value is the minimum number of OUTPUT buffers that is necessary for
> hardware
> to work.
>
> +
> + V4L2_CID_COLOR_ALPHA
> + integer
> + Sets the color alpha component on the capture device. It is
> + applicable to any pixel formats that contain the alpha component,
> + e.g. packed RGB image formats.
> +
> +
> +
> + V4L2_CID_LASTP1
> +
> + End of the predefined control IDs (currently
> + V4L2_CID_COLOR_ALPHA + 1).
> +
>
> V4L2_CID_PRIVATE_BASE
>
> diff --git a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
> b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
> index 4db272b..da4c360 100644
> --- a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
> +++ b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
> @@ -428,8 +428,11 @@ colorspace
> V4L2_COLORSPACE_SRGB.
> Bit 7 is the most significant bit. The value of a = alpha
> bits is undefined when reading from the driver, ignored when writing
> to the driver, except when alpha blending has been negotiated for a
> -Video Overlay or -linkend="osd">Video Output Overlay.
> +Video Overlay or
> +Video Output Overlay or when global alpha has been configured
> +for a Video Capture by means of
> + V4L2_CID_COLOR_ALPHA
> + control.
>
>
>V4L2_PIX_FMT_BGR24 4 × 4 pixel
> diff --git a/drivers/media/video/v4l2-ctrls.c
> b/drivers/media/video/v4l2-ctrls.c
> index 5552f81..bd90955 100644
> --- a/drivers/media/video/v4l2-ctrls.c
> +++ b/drivers/media/video/v4l2-ctrls.c
> @@ -466,6 +466,7 @@ const char *v4l2_ctrl_get_name(u32 id)
> case V4L2_CID_ILLUMINATORS_2: return "Illuminator 2";
> case V4L2_CID_MIN_BUFFERS_FOR_CAPTURE: return "Minimum Number of
> Capture Buffers";
> case V4L2_CID_MIN_BUFFERS_FOR_OUTPUT: return "Minimum Number of
> Output Buffers";
> + case V4L2_CID_COLOR_ALPHA: return "Color Alpha";
I prefer CID_ALPHA_COLOR and string "Alpha Color". I think it is more
natural than the other way around.
Other than that I'm OK with this.
Regards,
Hans
>
> /* MPEG controls */
> /* Keep the order of the 'case's the same as in videodev2.h! */
> @@ -714,6 +715,12 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
> v4l2_ctrl_type *type,
> /* Max is calculated as RGB888 that is 2^24 */
> *max = 0xFF;
> break;
> + case V4L2_CID_COLOR_ALPHA:
> + *type = V4L2_CTRL_TYPE_INTEGER;
> + *step = 1;
> + *min = 0;
> + *max = 0xff;
> + break;
> case V4L2_CID_FLASH_FAULT:
> *type = V4L2_CTRL_TYPE_BITMASK;
> break;
> diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> index 4b752d5..42192c1 100644
> --- a/include/linux/videodev2.h
> +++ b/include/linux/videodev2.h
> @@ -1204,10 +1204,10 @@ enum v4l2_colorfx {
> #define V4L2_CID_MIN_BUFFERS_FOR_CAPTURE (V4L2_CID_BASE+39)
> #define V4L2_CID_MIN_BUFFERS_FOR_OUTPUT (V4L2_CID_BASE+40)
>
> -/* last CID + 1 */
> -#define V4L2_CID_LASTP1 (V4L2_CID_BASE+41)
> +#define V4L2_CID_COLOR_ALPHA (V4L2_CID_BASE+41)
>
> -/* Minimum number of buffer neede by the device */
> +/* last CID + 1 */
> +#define V4L2_CID_LASTP1
[PATCH/RFC 1/2] v4l: Add a global color alpha control
This control is intended for video capture or memory-to-memory
devices that are capable of setting up the alpha conponent to
some arbitrary value.
The V4L2_CID_COLOR_ALPHA control allows to set the alpha channel
globally to a value in range from 0 to 255.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
Documentation/DocBook/media/v4l/controls.xml | 20 ++--
.../DocBook/media/v4l/pixfmt-packed-rgb.xml|7 +--
drivers/media/video/v4l2-ctrls.c |7 +++
include/linux/videodev2.h |6 +++---
4 files changed, 29 insertions(+), 11 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/controls.xml
b/Documentation/DocBook/media/v4l/controls.xml
index 3bc5ee8..7f99222 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -324,12 +324,6 @@ minimum value disables backlight compensation.
(usually a microscope).
- V4L2_CID_LASTP1
-
- End of the predefined control IDs (currently
-V4L2_CID_ILLUMINATORS_2 + 1).
-
-
V4L2_CID_MIN_BUFFERS_FOR_CAPTURE
integer
This is a read-only control that can be read by the
application
@@ -345,6 +339,20 @@ and used as a hint to determine the number of OUTPUT
buffers to pass to REQBUFS.
The value is the minimum number of OUTPUT buffers that is necessary for
hardware
to work.
+
+ V4L2_CID_COLOR_ALPHA
+ integer
+Sets the color alpha component on the capture device. It is
+ applicable to any pixel formats that contain the alpha component,
+ e.g. packed RGB image formats.
+
+
+
+ V4L2_CID_LASTP1
+
+ End of the predefined control IDs (currently
+ V4L2_CID_COLOR_ALPHA + 1).
+
V4L2_CID_PRIVATE_BASE
diff --git a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
index 4db272b..da4c360 100644
--- a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
@@ -428,8 +428,11 @@ colorspace
V4L2_COLORSPACE_SRGB.
Bit 7 is the most significant bit. The value of a = alpha
bits is undefined when reading from the driver, ignored when writing
to the driver, except when alpha blending has been negotiated for a
-Video Overlay or Video Output Overlay.
+Video Overlay or
+Video Output Overlay or when global alpha has been configured
+for a Video Capture by means of
+ V4L2_CID_COLOR_ALPHA
+ control.
V4L2_PIX_FMT_BGR24 4 × 4 pixel
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 5552f81..bd90955 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -466,6 +466,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_ILLUMINATORS_2: return "Illuminator 2";
case V4L2_CID_MIN_BUFFERS_FOR_CAPTURE: return "Minimum Number of
Capture Buffers";
case V4L2_CID_MIN_BUFFERS_FOR_OUTPUT: return "Minimum Number of
Output Buffers";
+ case V4L2_CID_COLOR_ALPHA: return "Color Alpha";
/* MPEG controls */
/* Keep the order of the 'case's the same as in videodev2.h! */
@@ -714,6 +715,12 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
/* Max is calculated as RGB888 that is 2^24 */
*max = 0xFF;
break;
+ case V4L2_CID_COLOR_ALPHA:
+ *type = V4L2_CTRL_TYPE_INTEGER;
+ *step = 1;
+ *min = 0;
+ *max = 0xff;
+ break;
case V4L2_CID_FLASH_FAULT:
*type = V4L2_CTRL_TYPE_BITMASK;
break;
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 4b752d5..42192c1 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1204,10 +1204,10 @@ enum v4l2_colorfx {
#define V4L2_CID_MIN_BUFFERS_FOR_CAPTURE (V4L2_CID_BASE+39)
#define V4L2_CID_MIN_BUFFERS_FOR_OUTPUT(V4L2_CID_BASE+40)
-/* last CID + 1 */
-#define V4L2_CID_LASTP1 (V4L2_CID_BASE+41)
+#define V4L2_CID_COLOR_ALPHA (V4L2_CID_BASE+41)
-/* Minimum number of buffer neede by the device */
+/* last CID + 1 */
+#define V4L2_CID_LASTP1 (V4L2_CID_BASE+42)
/* MPEG-class control IDs defined by V4L2 */
#define V4L2_CID_MPEG_BASE (V4L2_CTRL_CLASS_MPEG | 0x900)
--
1.7.7.2
--
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/RFC] Add V4L2_CID_COLOR_ALPHA control for global color alpha
Hello, This changeset adds new V4L2_CID_COLOR_ALPHA control that allows to configure per image plane color alpha value on the capture queue buffers. There was a short discussion in the past about the global alpha control support started by Jonghun Han: http://www.mail-archive.com/linux-media@vger.kernel.org/msg27128.html The second patch adds the control to s5p-fimc video capture and mem-to-mem driver. Sylwester Nawrocki (2): v4l: Add a global color alpha control s5p-fimc: Add support for global color alpha configuration Documentation/DocBook/media/v4l/controls.xml | 20 +-- .../DocBook/media/v4l/pixfmt-packed-rgb.xml|7 ++- drivers/media/video/s5p-fimc/fimc-capture.c|4 ++ drivers/media/video/s5p-fimc/fimc-core.c | 49 -- drivers/media/video/s5p-fimc/fimc-core.h | 13 - drivers/media/video/s5p-fimc/fimc-reg.c| 53 +++- drivers/media/video/s5p-fimc/regs-fimc.h |5 ++ drivers/media/video/v4l2-ctrls.c |7 +++ include/linux/videodev2.h |6 +- 9 files changed, 134 insertions(+), 30 deletions(-) -- Regards, Sylwester Nawrocki Samsung Poland R&D Center -- 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/2] s5p-fimc: Add support for global color alpha configuration
On Exynos SoCs the FIMC IP allows to configure globally the alpha
color channel for V4L2_PIX_FMT_RGB32, V4L2_PIX_FMT_RGB555 and
V4L2_PIX_FMT_RGB444 pixel formats. This patch adds a v4l2 control
in order to let the applications control the global alpha value.
The alpha value range depends on the pixel format, for RGB32
it's 0..255, for RGB555 - 0..1 and for RGB444 - 0..7. The v4l2
control range is always 0..255 and the driver will ignore most
significant bits of the alpha value where the alpha channel width
is less than 8 bits. The applications need to match the alpha
channel data width and the pixel format.
An option is added to the variant description data structure
so an additional control is created only where really supported
in hardware.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/video/s5p-fimc/fimc-capture.c |4 ++
drivers/media/video/s5p-fimc/fimc-core.c| 49 ++---
drivers/media/video/s5p-fimc/fimc-core.h| 13 ++-
drivers/media/video/s5p-fimc/fimc-reg.c | 53 +--
drivers/media/video/s5p-fimc/regs-fimc.h|5 +++
5 files changed, 105 insertions(+), 19 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 82d9ab6..70176e5 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -63,6 +63,8 @@ static int fimc_init_capture(struct fimc_dev *fimc)
fimc_hw_set_effect(ctx, false);
fimc_hw_set_output_path(ctx);
fimc_hw_set_out_dma(ctx);
+ if (fimc->variant->has_alpha)
+ fimc_hw_set_rgb_alpha(ctx);
clear_bit(ST_CAPT_APPLY_CFG, &fimc->state);
}
spin_unlock_irqrestore(&fimc->slock, flags);
@@ -154,6 +156,8 @@ int fimc_capture_config_update(struct fimc_ctx *ctx)
fimc_hw_set_rotation(ctx);
fimc_prepare_dma_offset(ctx, &ctx->d_frame);
fimc_hw_set_out_dma(ctx);
+ if (fimc->variant->has_alpha)
+ fimc_hw_set_rgb_alpha(ctx);
clear_bit(ST_CAPT_APPLY_CFG, &fimc->state);
}
spin_unlock(&ctx->slock);
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index 567e9ea..20f9da8 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -52,13 +52,29 @@ static struct fimc_fmt fimc_formats[] = {
.colplanes = 1,
.flags = FMT_FLAGS_M2M,
}, {
- .name = "XRGB-8-8-8-8, 32 bpp",
+ .name = "XRGB, 32 bpp",
.fourcc = V4L2_PIX_FMT_RGB32,
.depth = { 32 },
.color = S5P_FIMC_RGB888,
.memplanes = 1,
.colplanes = 1,
- .flags = FMT_FLAGS_M2M,
+ .flags = FMT_FLAGS_M2M | FMT_HAS_ALPHA,
+ }, {
+ .name = "ARGB1555",
+ .fourcc = V4L2_PIX_FMT_RGB555,
+ .depth = { 16 },
+ .color = S5P_FIMC_RGB555,
+ .memplanes = 1,
+ .colplanes = 1,
+ .flags = FMT_FLAGS_M2M | FMT_HAS_ALPHA,
+ }, {
+ .name = "ARGB",
+ .fourcc = V4L2_PIX_FMT_RGB444,
+ .depth = { 16 },
+ .color = S5P_FIMC_RGB444,
+ .memplanes = 1,
+ .colplanes = 1,
+ .flags = FMT_FLAGS_M2M | FMT_HAS_ALPHA,
}, {
.name = "YUV 4:2:2 packed, YCbYCr",
.fourcc = V4L2_PIX_FMT_YUYV,
@@ -652,8 +668,11 @@ static void fimc_dma_run(void *priv)
if (ctx->state & (FIMC_DST_ADDR | FIMC_PARAMS))
fimc_hw_set_output_addr(fimc, &ctx->d_frame.paddr, -1);
- if (ctx->state & FIMC_PARAMS)
+ if (ctx->state & FIMC_PARAMS) {
fimc_hw_set_out_dma(ctx);
+ if (fimc->variant->has_alpha)
+ fimc_hw_set_rgb_alpha(ctx);
+ }
fimc_activate_capture(ctx);
@@ -790,6 +809,11 @@ static int fimc_s_ctrl(struct v4l2_ctrl *ctrl)
ctx->rotation = ctrl->val;
break;
+ case V4L2_CID_COLOR_ALPHA:
+ spin_lock_irqsave(&ctx->slock, flags);
+ ctx->d_frame.alpha = ctrl->val;
+ break;
+
default:
v4l2_err(fimc->v4l2_dev, "Invalid control: 0x%X\n", ctrl->id);
return -EINVAL;
@@ -806,9 +830,11 @@ static const struct v4l2_ctrl_ops fimc_ctrl_ops = {
int fimc_ctrls_create(struct fimc_ctx *ctx)
{
+ struct samsung_fimc_variant *variant = ctx->f
Re: [PATCH v3 1/3] fbdev: Add FOURCC-based format configuration API
Hi Florian,
Gentle ping ?
On Sunday 20 November 2011 11:55:22 Laurent Pinchart wrote:
> On Sunday 20 November 2011 03:00:33 Florian Tobias Schandinat wrote:
> > Hi Laurent,
> >
> > On 08/31/2011 11:18 AM, Laurent Pinchart wrote:
> > > This API will be used to support YUV frame buffer formats in a standard
> > > way.
> >
> > looks like the union is causing problems. With this patch applied I get
> >
> > errors like this:
> > CC [M] drivers/auxdisplay/cfag12864bfb.o
> >
> > drivers/auxdisplay/cfag12864bfb.c:57: error: unknown field ‘red’
> > specified in initializer
>
> *ouch*
>
> gcc < 4.6 chokes on anonymous unions initializers :-/
>
> [snip]
>
> > > @@ -246,12 +251,23 @@ struct fb_var_screeninfo {
> > >
> > > __u32 yoffset; /* resolution */
> > >
> > > __u32 bits_per_pixel; /* guess what */
> > >
> > > - __u32 grayscale;/* != 0 Graylevels instead of colors */
> > >
> > > - struct fb_bitfield red; /* bitfield in fb mem if true color, */
> > > - struct fb_bitfield green; /* else only length is significant */
> > > - struct fb_bitfield blue;
> > > - struct fb_bitfield transp; /* transparency */
> > > + union {
> > > + struct {/* Legacy format API*/
> > > + __u32 grayscale; /* 0 = color, 1 = grayscale*/
> > > + /* bitfields in fb mem if true color, else only */
> > > + /* length is significant*/
> > > + struct fb_bitfield red;
> > > + struct fb_bitfield green;
> > > + struct fb_bitfield blue;
> > > + struct fb_bitfield transp; /* transparency */
> > > + };
> > > + struct {/* FOURCC-based format API */
> > > + __u32 fourcc; /* FOURCC format*/
> > > + __u32 colorspace;
> > > + __u32 reserved[11];
> > > + } fourcc;
> > > + };
>
> We can't name the union, otherwise this will change the userspace API.
>
> We could "fix" the problem on the kernel side with
>
> #ifdef __KERNEL__
> } color;
> #else
> };
> #endif
(and the structure that contains the grayscale, red, green, blue and transp
fields would need to be similarly named, the "rgb" name comes to mind)
> That's quite hackish though... What's your opinion ?
>
> It would also not handle userspace code that initializes an
> fb_var_screeninfo structure with named initializers, but that shouldn't
> happen, as application should read fb_var_screeninfo , modify it and write
> it back.
>
> > > __u32 nonstd; /* != 0 Non standard pixel format */
--
Regards,
Laurent Pinchart
--
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 request for 3.2 (fixes 'n' features)
Hi Mauro, On Tue, 4 Oct 2011, Patrick Boettcher wrote: Hi Mauro, if it's not too late for 3.2 could you please pull from git://linuxtv.org/pb/media_tree.git staging/for_v3.2 for [media] dib9090: limit the I2C speed [media] dib8096P: add the reference board [media] add the support for DiBcom [media] dib7090: add the reference board [media] DiB8000: improve the tuning and the SNR monitoring [media] DiBcom: correct warnings [media] dib7090: add the reference board TFE7090E [media] dib7000p/dib0090: update the driver I think this PULL request got lost. (as usual for my pull-requests :( ). It was meant for 3.2 and was sent in advance. Do you think you will get it in? regards, -- Patrick Boettcher - 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: [Query] V4L2 Integer (?) menu control
Thank you all for the comments. On 11/24/2011 09:50 AM, Sakari Ailus wrote: > Hi Sylwester, > > There is not currently, but I have patches for it. The issue is that I need > them myself but the driver I need them for isn't ready to be released yet. > And as usual, I assume others than vivo is required to show they're really > useful so I haven't sent them. That's great news. Then I might not need to do all the work on my own;) > > Good that you asked so we won't end up writing essentially the same code > again. I'll try to send the patches today. All right, there is no rush. I was just looking around how to support the camera scene mode with m5mols sort of sensors. The scene mode is essentially a compilation of several different parameters, for some of which there are standard controls in V4L2 but for many there are not. I've got a feeling the best way to handle this would be to create controls for each single parameter and then do a batch set from user space, and keep the scene mode mappings in user space. The only concern is there is a couple of ISP-specific parameters involved with that scene mode thing. Perhaps they just could be set initially to fixed values. -- Regards, Sylwester -- 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: [Query] V4L2 Integer (?) menu control
On 11/24/2011 07:24 AM, Rémi Denis-Courmont wrote: > On Wed, 23 Nov 2011 23:26:22 +0100, Sylwester Nawrocki > wrote: >> I don't seem to find a way to implement this in current v4l2 control >> framework. Such functionality isn't there, or is it ? > > You can use the menu control type, but you will need to remap the control > values so they are continuous. Yes, but what I'm missing is a method for the drivers to inform the application how the mapping looks like. Something like custom queryctrl for standard control CID. So for instance if we have a standard control V4L2_CID_CAMERA_ISO, two devices could support different series of values, e.g. 50, 200, 400, 800, .. 100, 180, 300, 600, ... Currently the menu items are hard coded in the kernel for standard controls, and AFAIU we can only query the control names. In fact the continuous enumeration in the driver might do, which would be then mapped to register values. But the meaning of this values need to be made known to the applications. -- Thanks, Sylwester -- 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/2] staging/media: lirc_imon: remove unused definitions
We don't have these functions any more now we have module_usb_driver(). Signed-off-by: Dan Carpenter --- I don't know if this goes in through USB or the media tree. diff --git a/drivers/staging/media/lirc/lirc_imon.c b/drivers/staging/media/lirc/lirc_imon.c index f682180..c3eae4d 100644 --- a/drivers/staging/media/lirc/lirc_imon.c +++ b/drivers/staging/media/lirc/lirc_imon.c @@ -70,10 +70,6 @@ static ssize_t vfd_write(struct file *file, const char *buf, static int ir_open(void *data); static void ir_close(void *data); -/* Driver init/exit prototypes */ -static int __init imon_init(void); -static void __exit imon_exit(void); - /*** G L O B A L S ***/ #define IMON_DATA_BUF_SZ 35 -- 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 1/2] staging/media: lirc_imon: add a __user annotation
This silences the following Sparse warnings:
lirc_imon.c:404:32: warning: incorrect type in argument 1 (different address
spaces)
lirc_imon.c:404:32:expected void const [noderef] *
lirc_imon.c:404:32:got char const *buf
lirc_imon.c:117:28: warning: incorrect type in initializer (incompatible
argument 2 (different address spaces))
lirc_imon.c:117:28:expected long ( *write )( ... )
lirc_imon.c:117:28:got long ( static [toplevel] * )( ... )
Signed-off-by: Dan Carpenter
diff --git a/drivers/staging/media/lirc/lirc_imon.c
b/drivers/staging/media/lirc/lirc_imon.c
index f682180..5f7f8cd 100644
--- a/drivers/staging/media/lirc/lirc_imon.c
+++ b/drivers/staging/media/lirc/lirc_imon.c
@@ -63,7 +63,7 @@ static int display_open(struct inode *inode, struct file
*file);
static int display_close(struct inode *inode, struct file *file);
/* VFD write operation */
-static ssize_t vfd_write(struct file *file, const char *buf,
+static ssize_t vfd_write(struct file *file, const char __user *buf,
size_t n_bytes, loff_t *pos);
/* LIRC driver function prototypes */
@@ -369,7 +369,7 @@ static int send_packet(struct imon_context *context)
* than 32 bytes are provided spaces will be appended to
* generate a full screen.
*/
-static ssize_t vfd_write(struct file *file, const char *buf,
+static ssize_t vfd_write(struct file *file, const char __user *buf,
size_t n_bytes, loff_t *pos)
{
int i;
--
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: [Query] V4L2 Integer (?) menu control
On Wed, Nov 23, 2011 at 11:26:22PM +0100, Sylwester Nawrocki wrote: > Hi, > > I was wondering how to implement in v4l2 a standard menu control having > integer > values as the menu items. The menu item values would be irregular, e.g. > ascending > logarithmically and thus the step value would not be a constant. > I'm not interested in private control and symbolic enumeration for each value > at > the series. It should be a standard control where drivers could define an > array > of integers reflecting the control menu items. And then the applications could > enumerate what integer values are valid and can be happily applied to a > device. > > I don't seem to find a way to implement this in current v4l2 control > framework. > Such functionality isn't there, or is it ? Hi Sylwester, There is not currently, but I have patches for it. The issue is that I need them myself but the driver I need them for isn't ready to be released yet. And as usual, I assume others than vivo is required to show they're really useful so I haven't sent them. Good that you asked so we won't end up writing essentially the same code again. I'll try to send the patches today. Kind regards, -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- 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: [Query] V4L2 Integer (?) menu control
On Wednesday, November 23, 2011 23:26:22 Sylwester Nawrocki wrote: > Hi, > > I was wondering how to implement in v4l2 a standard menu control having > integer > values as the menu items. The menu item values would be irregular, e.g. > ascending > logarithmically and thus the step value would not be a constant. > I'm not interested in private control and symbolic enumeration for each value > at > the series. It should be a standard control where drivers could define an > array > of integers reflecting the control menu items. And then the applications could > enumerate what integer values are valid and can be happily applied to a > device. > > I don't seem to find a way to implement this in current v4l2 control > framework. > Such functionality isn't there, or is it ? No it doesn't exist. I'd have sworn that I saw a proposal for adding something like that on the mailinglist some time ago, but I can't find it anymore. It wouldn't be difficult to add. 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
