Re: why is there no enum_input in v4l2_subdev_video_ops
> Hi Scott, > > On Wednesday 11 May 2011 10:43:30 Jiang, Scott wrote: >> On Tue, May 10, 2011 at 5:51 PM, Laurent Pinchart wrote: > > On Tuesday >> 10 > May 2011 08:14:10 Hans Verkuil wrote: >> >> > On Tue, May 10, 2011 at 5:42 AM, Laurent Pinchart wrote: >> >> >>> >> Why is there no enum_input operation in v4l2_subdev_video_ops? >> >> >> >> >> >> Why do you need one ? >> >> > >> >> > Because I want to query decoder how many inputs it can support. >> >> > So the question is where we should store inputs info, board >> specific >> >> > data or decoder driver? >> >> > I appreciate your advice. >> >> >> >> ENUMINPUT as defined by V4L2 enumerates input connectors available on >> >> the board. Which inputs the board designer hooked up is something >> that >> >> only the top-level V4L driver will know. Subdevices do not have that >> >> information, so enuminputs is not applicable there. >> >> >> >> Of course, subdevices do have input pins and output pins, but these >> are >> >> assumed to be fixed. With the s_routing ops the top level driver >> selects >> >> which input and output pins are active. Enumeration of those inputs >> and >> >> outputs wouldn't gain you anything as far as I can tell since the >> >> subdevice simply does not know which inputs/outputs are actually >> hooked >> >> up. It's the top level driver that has that information (usually >> passed >> >> in through board/card info structures). >> > >> > I agree. Subdevs don't have enough knowledge of their surroundings to >> > make input enumeration really useful. They could enumerate their input >> > pins, but not the inputs that are actually hooked up on board. >> > >> > The media controller framework is one way of solving this issue. It >> can >> > report links for every input pad. >> > >> > Scott, can you tell us a bit more about the decoder you're working >> with ? >> > What kind of system is it used in ? >> >> I'm working on ADV7183 and VS6624 connecting with blackfin through ppi. > > Enumerating inputs only matters for the ADV7183. The issue is that the > adv7183 > driver doesn't know how its inputs are routed on the board. I see several > solutions to fix this issue. > > - Create an adv7183 platform data structure, and fill it in board code > with > input routing information. The adv7183 driver can use that information to > implement a (to be added) enum_input operation. I don't really like this > solution, as the adv7183 really shouldn't care about how video signals are > routed on the board. Definitely not. > - Pass the same information to the master v4l2_device driver that > instantiates > the adv7183. The information can then be used to implement the G_INPUT > ioctl, > or for internal purpose. You won't need any enum_input subdev operation in > that case. This is the way to do it. The TI davinci drivers do this, for example. > - Use the media controller API to expose routing information to userspace. > Like in the previous solution, board code would pass input routing > information > to the v4l2_device driver that would use use to create links. Links will > then > be enumerable and configurable by userspace. This does not work (yet), since this would require the MC to have connector entities which we do not have (yet). We will need them for ALSA, and I think we also need them for V4L, but for V4L we need to figure out the relationship between the _INPUT and _OUTPUT V4L2 ioctls and a MC with connector entities first. Regards, Hans >> By the way, ppi is a generic parallel interface, that means it can't >> know >> the fmt supported itself. Should I use enum_mbus_fmt to ask decoder for >> this info? >> I found it in v4l2_subdev_video_ops, but didn't know its usage exactly. > > The enum_mbus_fmt can be used for that purpose, yes. You can use it to > query > the ADV7183 and VS6624 for their supported formats. You can also query the > current format with g_mbus_fmt. > > If you want to implement the media controller API, you should go for the > pad- > level operations instead of enum_mbus_fmt/g_mbus_fmt (available in > 2.6.39). > > -- > 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 > -- 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 remote control autorepeat / evdev
On Thu, May 12, 2011 at 03:36:47AM +0200, Mauro Carvalho Chehab wrote: > Em 12-05-2011 03:10, Mauro Carvalho Chehab escreveu: > > Em 12-05-2011 02:37, Anssi Hannula escreveu: > > >> I don't see any other places: > >> $ git grep 'REP_PERIOD' . > >> dvb/dvb-usb/dvb-usb-remote.c: input_dev->rep[REP_PERIOD] = > >> d->props.rc.legacy.rc_interval; > > > > Indeed, the REP_PERIOD is not adjusted on other drivers. I agree that we > > should change it to something like 125ms, for example, as 33ms is too > > short, as it takes up to 114ms for a repeat event to arrive. > > > IMO, the enclosed patch should do a better job with repeat events, without > needing to change rc-core/input/event logic. > > - > > Subject: Use a more consistent value for RC repeat period > From: Mauro Carvalho Chehab > > The default REP_PERIOD is 33 ms. This doesn't make sense for IR's, > as, in general, an IR repeat scancode is provided at every 110/115ms, > depending on the RC protocol. So, increase its default, to do a > better job avoiding ghost repeat events. > > Signed-off-by: Mauro Carvalho Chehab > > diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c > index f53f9c6..ee67169 100644 > --- a/drivers/media/rc/rc-main.c > +++ b/drivers/media/rc/rc-main.c > @@ -1044,6 +1044,13 @@ int rc_register_device(struct rc_dev *dev) >*/ > dev->input_dev->rep[REP_DELAY] = 500; > > + /* > + * As a repeat event on protocols like RC-5 and NEC take as long as > + * 110/114ms, using 33ms as a repeat period is not the right thing > + * to do. > + */ > + dev->input_dev->rep[REP_PERIOD] = 125; > + > path = kobject_get_path(&dev->dev.kobj, GFP_KERNEL); > printk(KERN_INFO "%s: %s as %s\n", > dev_name(&dev->dev), so if I get this right, a XkbSetControls(.. XkbRepeatKeysMask ...) by a client to set the repeat rate would provide the same solution - for those clients/devices affected. The interesting question is how clients would identify the devices that are affected by this (other than trial and error). Cheers, Peter -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Audio Video synchronization for data received from a HDMI receiver chip
Hi Linux media folks, We are considering putting an advanced HDMI receiver chip on our SoC, to allow reception of HDMI audio and video. The chip receives HDMI data from a host like a set-up box or DVD player. It provides a video data interface and SPDIF/I2S audio data interface. We plan to support the HDMI video using the V4L2 framework and the HDMI audio using ALSA framework. Now, what seems to be intriguing us is how the audio-video synchronization will be maintained? Will a separate bridging entity required to ensure the same or whether this can be left upon a user space application like mplayer or gstreamer. Also is there a existing interface between the V4L2 and ALSA frameworks and the same can be used in our design? Regards, Bhupesh ST Microelectronics -- 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 remote control autorepeat / evdev
On May 11, 2011, at 9:36 PM, Mauro Carvalho Chehab wrote: > Em 12-05-2011 03:10, Mauro Carvalho Chehab escreveu: >> Em 12-05-2011 02:37, Anssi Hannula escreveu: > >>> I don't see any other places: >>> $ git grep 'REP_PERIOD' . >>> dvb/dvb-usb/dvb-usb-remote.c: input_dev->rep[REP_PERIOD] = >>> d->props.rc.legacy.rc_interval; >> >> Indeed, the REP_PERIOD is not adjusted on other drivers. I agree that we >> should change it to something like 125ms, for example, as 33ms is too >> short, as it takes up to 114ms for a repeat event to arrive. >> > IMO, the enclosed patch should do a better job with repeat events, without > needing to change rc-core/input/event logic. > > - > > Subject: Use a more consistent value for RC repeat period > From: Mauro Carvalho Chehab > > The default REP_PERIOD is 33 ms. This doesn't make sense for IR's, > as, in general, an IR repeat scancode is provided at every 110/115ms, > depending on the RC protocol. So, increase its default, to do a > better job avoiding ghost repeat events. > > Signed-off-by: Mauro Carvalho Chehab Yeah, I definitely like this change, and I think it should do some good. I've been pointing a number of people at ir-keytable and its ability to tweak these values from userspace. Most people have been bumping REP_PERIOD up a bit, but also REP_DELAY down a bit, so that repeats actually kick in a bit sooner. I'm fine with leaving 500 as the default there though, and letting individual drivers adjust it if they really want. Acked-by: Jarod Wilson -- Jarod Wilson ja...@wilsonet.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: IR remote control autorepeat / evdev
Em 12-05-2011 03:10, Mauro Carvalho Chehab escreveu: > Em 12-05-2011 02:37, Anssi Hannula escreveu: >> I don't see any other places: >> $ git grep 'REP_PERIOD' . >> dvb/dvb-usb/dvb-usb-remote.c: input_dev->rep[REP_PERIOD] = >> d->props.rc.legacy.rc_interval; > > Indeed, the REP_PERIOD is not adjusted on other drivers. I agree that we > should change it to something like 125ms, for example, as 33ms is too > short, as it takes up to 114ms for a repeat event to arrive. > IMO, the enclosed patch should do a better job with repeat events, without needing to change rc-core/input/event logic. - Subject: Use a more consistent value for RC repeat period From: Mauro Carvalho Chehab The default REP_PERIOD is 33 ms. This doesn't make sense for IR's, as, in general, an IR repeat scancode is provided at every 110/115ms, depending on the RC protocol. So, increase its default, to do a better job avoiding ghost repeat events. Signed-off-by: Mauro Carvalho Chehab diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c index f53f9c6..ee67169 100644 --- a/drivers/media/rc/rc-main.c +++ b/drivers/media/rc/rc-main.c @@ -1044,6 +1044,13 @@ int rc_register_device(struct rc_dev *dev) */ dev->input_dev->rep[REP_DELAY] = 500; + /* +* As a repeat event on protocols like RC-5 and NEC take as long as +* 110/114ms, using 33ms as a repeat period is not the right thing +* to do. +*/ + dev->input_dev->rep[REP_PERIOD] = 125; + path = kobject_get_path(&dev->dev.kobj, GFP_KERNEL); printk(KERN_INFO "%s: %s as %s\n", dev_name(&dev->dev), -- 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 remote control autorepeat / evdev
Em 12-05-2011 02:37, Anssi Hannula escreveu: > On 12.05.2011 02:52, Mauro Carvalho Chehab wrote: >> Em 11-05-2011 19:59, Anssi Hannula escreveu: No. It actually depends on what driver you're using. For example, for most dvb-usb devices, this is given by the logic bellow: if (d->props.rc.legacy.rc_interval < 40) d->props.rc.legacy.rc_interval = 100; /* default */ input_dev->rep[REP_PERIOD] = d->props.rc.legacy.rc_interval; input_dev->rep[REP_DELAY] = d->props.rc.legacy.rc_interval + 150; where the rc_interval defined by device entry at the dvb usb drivers. >>> >>> Isn't that function only called for DVB_RC_LEGACY mode? >> >> I just picked one random piece of the code that covers several RC remotes >> (most >> dvb-usb drivers are still using the legacy mode). Similar code are there for >> other devices. > > I don't see any other places: > $ git grep 'REP_PERIOD' . > dvb/dvb-usb/dvb-usb-remote.c: input_dev->rep[REP_PERIOD] = > d->props.rc.legacy.rc_interval; Indeed, the REP_PERIOD is not adjusted on other drivers. I agree that we should change it to something like 125ms, for example, as 33ms is too short, as it takes up to 114ms for a repeat event to arrive. The REP_PERIOD is adjusted, however, on several drivers. Also, RC core changes its default to 500ms, to avoid ghost keystrokes: dev->input_dev->rep[REP_DELAY] = 500; > >>> Maybe I wasn't clear, but I'm talking only about the devices handled by >>> rc-core. >> >> With just a few exceptions, the repeat period/delay that were there before >> porting to rc-core were maintained. There are space for adjustments, as we >> did on a few cases. > > The above is the only place where the repeat period is set in the > drivers/media tree, and it is not an rc-core device. Other devices > therefore use the 33ms kernel default. > > Maybe I am missing something? > >> Em 11-05-2011 22:53, Dmitry Torokhov escreveu: >>> On Wed, May 11, 2011 at 08:59:16PM +0300, Anssi Hannula wrote: I meant replacing the softrepeat with native repeat for such devices that have native repeats but no native release events: - keypress from device => keydown + keyup - repeat from device => keydown + keyup - repeat from device => keydown + keyup This is what e.g. ati_remote driver now does. Or alternatively - keypress from device => keydown - repeat from device => repeat - repeat from device => repeat - nothing for 250ms => keyup (doing it this way requires some extra handling in X server to stop its softrepeat from triggering, though, as previously noted) With either of these, if one holds down volumeup, the repeat works, and stops volumeup'ing immediately when user releases the button (as it is supposed to). >>> >>> Unfortunately this does not work for devices that do not have hardware >>> autorepeat and also stops users from adjusting autorepeat parameters to >>> their liking. >> >> Yes. A solution like the above would limit the usage. There are some remotes >> (like for example, the Hauppauge Grey remotes I have here) that a simple >> keypress generates, in general, up to 3 scancodes (the normal keypress and >> up to two "bounced" repeat keycodes). So, the software key delay also serves >> as a way to de-bounce the keypress. > > I probably forgot to mention it, but I'm not suggesting removal of the > repetition delay (500ms), it can stay for this reason exactly. > >>> It appears that the delay to check whether the key has been released is >>> too long (almost order of magnitude longer than our typical autorepeat >>> period). >> >> Yes, because, for example, with NEC and RC-5 protocols, one keystroke or one >> repeat event takes 110/114 ms to be transmitted. The delay actually varies >> from protocol to protocol, so it is possible to do some adjustments, based on >> the protocol type, but it is an order of magnitude longer than a keyboard or >> mouse. >> >>> I think we should increase the period for remotes (both in >>> kernel and in X, and also see if the release check delay can be made >>> shorter, like 50-100 ms. >> >> Some adjustments like that can be made, but they are device-driver specific. >> >> For example, some in-hardware IR decoders with KS007 micro-controller just >> removes all repeat keycodes and replace them with new keystrokes. There are >> some shipped remotes that don't support the RC-5 or NEC key repeat event. So, >> on those, if you keep a key pressed, you just receive the same scancode >> several >> times. >> >> The last time I double checked all remotes I have here, on all cases the >> auto-repeat >> logic were doing the right job, but I won't doubt that we need to add some >> additional >> adjustments for some boards/devices. > > Does "doing the right job" mean that you are getting zero repeat (2) > events after releasing a remote button? I mean that the l
Re: IR remote control autorepeat / evdev
Em 12-05-2011 02:17, Anssi Hannula escreveu: > On 11.05.2011 23:53, Dmitry Torokhov wrote: >> On Wed, May 11, 2011 at 08:59:16PM +0300, Anssi Hannula wrote: >>> >>> I meant replacing the softrepeat with native repeat for such devices >>> that have native repeats but no native release events: >>> >>> - keypress from device => keydown + keyup >>> - repeat from device => keydown + keyup >>> - repeat from device => keydown + keyup >>> >>> This is what e.g. ati_remote driver now does. >>> >>> Or alternatively >>> >>> - keypress from device => keydown >>> - repeat from device => repeat >>> - repeat from device => repeat >>> - nothing for 250ms => keyup >>> (doing it this way requires some extra handling in X server to stop its >>> softrepeat from triggering, though, as previously noted) >>> >>> With either of these, if one holds down volumeup, the repeat works, and >>> stops volumeup'ing immediately when user releases the button (as it is >>> supposed to). >>> >> >> Unfortunately this does not work for devices that do not have hardware >> autorepeat > > Devices that have no hardware autorepeat have hardware release events, > no? I'm only suggesting to do this for devices with hardware autorepeat. What I meant to say is that some devices produce: ... instead of: ... In other words, there's not a solution that fits all. Adjustments need to be done per device, and not as a change at the core. > If there are no hw repeat events and no hw release events, obviously > making repeat work at all is impossible. > >> and also stops users from adjusting autorepeat parameters to >> their liking. > > True. However, I don't think adjustable autorepeat parameters are much > of use for the users if the autorepeat itself is unusable (due to ghost > repeats). > >> It appears that the delay to check whether the key has been released is >> too long (almost order of magnitude longer than our typical autorepeat >> period). I think we should increase the period for remotes (both in >> kernel and in X, and also see if the release check delay can be made >> shorter, like 50-100 ms. > > To make the ghost repeat issue disappear, one would have to use a > release timeout of just over the native repeat rate of the remote, and a > softrepeat period of just over the release timeout, right? There's no known "ghost repeat" issue at rc-core. If you're seeing an issue, it is probably device-specific, and should be handle are such. Don't blame the core [1]. On what device(s) are you noticing such ghost repeat, and with what protocols? please provide the rc-core and driver-specific debug information and let's work to fix on the case you've detected. [1] I'm referring to the way input/event is providing the events. If Xorg is discarding the in-kernel repeat logic and using its own logic, then we may have ghost events there, as RC timings are different than keyboards. So a 250/33 would produce a crappy result with RC's. > This will make the repeat rate slower than the native repeats. I'm not > 100% sure if that is an issue, but I'd guess there might be some devices > that already have a slowish repeat rate, where we wouldn't want to add > such additional delay. If we use the native repeat, we would have one keystroke on every 110ms, and the initial delay would be also 110ms. On my experiences, while repeating keys close to 110ms is generally ok, 110ms is too short for the initial events, especially due to the debouncing. Depending on the RC device, as I said before, a normal keypress in general produces more than just one event, due to debounce issues. In other words, It really doesn't makes sense to wait for 250ms at a keyboard to start repeat, and to wait for just 110ms to start repeat at IR. The rc-core logic does the right thing here: - a keystroke generates a key down and starts a timer; - a repeat event (or the same keypress) resets the timer; - at timer's timeout, it produces a keyup. This way, the input-event knows when the key was pressed and when the key were released, and can produce repeat events at the right way, provided that the timer periods are compatible with the timings generated by the IR protocol. So, all that it is needed is to adjust the two EV_REP timings (delay and period) and the rc-core timer's timeout to remove the ghost effects. It is possible to control two of the 2 EV_REP timers via userspace. For now, we're using just one timer for the rc-core logic (IR_KEYPRESS_TIMEOUT, currently hardcoded as 250 ms). Such value is a little bigger than 2 x 114 ms, to avoid bouncing effects with RC-5 REPEAT events. Values smaller than 230 ms produced ghost keystrokes on some tests I did at the time such logic were added. > > (plus there is the issue of having to fiddle the rates for every > device/protocol) > -- 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.k
Re: IR remote control autorepeat / evdev
On 12.05.2011 02:52, Mauro Carvalho Chehab wrote: > Em 11-05-2011 19:59, Anssi Hannula escreveu: >>> No. It actually depends on what driver you're using. For example, for most >>> dvb-usb >>> devices, this is given by the logic bellow: >>> >>> if (d->props.rc.legacy.rc_interval < 40) >>> d->props.rc.legacy.rc_interval = 100; /* default */ >>> >>> input_dev->rep[REP_PERIOD] = d->props.rc.legacy.rc_interval; >>> input_dev->rep[REP_DELAY] = d->props.rc.legacy.rc_interval + 150; >>> >>> where the rc_interval defined by device entry at the dvb usb drivers. >> >> Isn't that function only called for DVB_RC_LEGACY mode? > > I just picked one random piece of the code that covers several RC remotes > (most > dvb-usb drivers are still using the legacy mode). Similar code are there for > other devices. I don't see any other places: $ git grep 'REP_PERIOD' . dvb/dvb-usb/dvb-usb-remote.c: input_dev->rep[REP_PERIOD] = d->props.rc.legacy.rc_interval; >> Maybe I wasn't clear, but I'm talking only about the devices handled by >> rc-core. > > With just a few exceptions, the repeat period/delay that were there before > porting to rc-core were maintained. There are space for adjustments, as we > did on a few cases. The above is the only place where the repeat period is set in the drivers/media tree, and it is not an rc-core device. Other devices therefore use the 33ms kernel default. Maybe I am missing something? > Em 11-05-2011 22:53, Dmitry Torokhov escreveu: >> On Wed, May 11, 2011 at 08:59:16PM +0300, Anssi Hannula wrote: >>> >>> I meant replacing the softrepeat with native repeat for such devices >>> that have native repeats but no native release events: >>> >>> - keypress from device => keydown + keyup >>> - repeat from device => keydown + keyup >>> - repeat from device => keydown + keyup >>> >>> This is what e.g. ati_remote driver now does. >>> >>> Or alternatively >>> >>> - keypress from device => keydown >>> - repeat from device => repeat >>> - repeat from device => repeat >>> - nothing for 250ms => keyup >>> (doing it this way requires some extra handling in X server to stop its >>> softrepeat from triggering, though, as previously noted) >>> >>> With either of these, if one holds down volumeup, the repeat works, and >>> stops volumeup'ing immediately when user releases the button (as it is >>> supposed to). >>> >> >> Unfortunately this does not work for devices that do not have hardware >> autorepeat and also stops users from adjusting autorepeat parameters to >> their liking. > > Yes. A solution like the above would limit the usage. There are some remotes > (like for example, the Hauppauge Grey remotes I have here) that a simple > keypress generates, in general, up to 3 scancodes (the normal keypress and > up to two "bounced" repeat keycodes). So, the software key delay also serves > as a way to de-bounce the keypress. I probably forgot to mention it, but I'm not suggesting removal of the repetition delay (500ms), it can stay for this reason exactly. >> It appears that the delay to check whether the key has been released is >> too long (almost order of magnitude longer than our typical autorepeat >> period). > > Yes, because, for example, with NEC and RC-5 protocols, one keystroke or one > repeat event takes 110/114 ms to be transmitted. The delay actually varies > from protocol to protocol, so it is possible to do some adjustments, based on > the protocol type, but it is an order of magnitude longer than a keyboard or > mouse. > >> I think we should increase the period for remotes (both in >> kernel and in X, and also see if the release check delay can be made >> shorter, like 50-100 ms. > > Some adjustments like that can be made, but they are device-driver specific. > > For example, some in-hardware IR decoders with KS007 micro-controller just > removes all repeat keycodes and replace them with new keystrokes. There are > some shipped remotes that don't support the RC-5 or NEC key repeat event. So, > on those, if you keep a key pressed, you just receive the same scancode > several > times. > > The last time I double checked all remotes I have here, on all cases the > auto-repeat > logic were doing the right job, but I won't doubt that we need to add some > additional > adjustments for some boards/devices. Does "doing the right job" mean that you are getting zero repeat (2) events after releasing a remote button? Because that is what I expect to happen, and that is what e.g. LIRC (which most people seem to still use with HTPC software - like XBMC which I'm a developer of) does. > Anssi, what's the hardware that you're using? I'm using ati_remote ported to rc-core (don't know yet if it makes any sense, though). However, as noted, reading ir-main.c I fail to see why this wouldn't happen with all rc-core devices, as all devices seem to use same IR_KEYPRESS_TIMEOUT and REP_PERIOD (though you seem to suggest otherwise above, maybe you can show me wrong? :) ). -- An
Re: IR remote control autorepeat / evdev
On 11.05.2011 23:53, Dmitry Torokhov wrote: > On Wed, May 11, 2011 at 08:59:16PM +0300, Anssi Hannula wrote: >> >> I meant replacing the softrepeat with native repeat for such devices >> that have native repeats but no native release events: >> >> - keypress from device => keydown + keyup >> - repeat from device => keydown + keyup >> - repeat from device => keydown + keyup >> >> This is what e.g. ati_remote driver now does. >> >> Or alternatively >> >> - keypress from device => keydown >> - repeat from device => repeat >> - repeat from device => repeat >> - nothing for 250ms => keyup >> (doing it this way requires some extra handling in X server to stop its >> softrepeat from triggering, though, as previously noted) >> >> With either of these, if one holds down volumeup, the repeat works, and >> stops volumeup'ing immediately when user releases the button (as it is >> supposed to). >> > > Unfortunately this does not work for devices that do not have hardware > autorepeat Devices that have no hardware autorepeat have hardware release events, no? I'm only suggesting to do this for devices with hardware autorepeat. If there are no hw repeat events and no hw release events, obviously making repeat work at all is impossible. > and also stops users from adjusting autorepeat parameters to > their liking. True. However, I don't think adjustable autorepeat parameters are much of use for the users if the autorepeat itself is unusable (due to ghost repeats). > It appears that the delay to check whether the key has been released is > too long (almost order of magnitude longer than our typical autorepeat > period). I think we should increase the period for remotes (both in > kernel and in X, and also see if the release check delay can be made > shorter, like 50-100 ms. To make the ghost repeat issue disappear, one would have to use a release timeout of just over the native repeat rate of the remote, and a softrepeat period of just over the release timeout, right? This will make the repeat rate slower than the native repeats. I'm not 100% sure if that is an issue, but I'd guess there might be some devices that already have a slowish repeat rate, where we wouldn't want to add such additional delay. (plus there is the issue of having to fiddle the rates for every device/protocol) -- Anssi Hannula -- 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 remote control autorepeat / evdev
Em 11-05-2011 19:59, Anssi Hannula escreveu: >> No. It actually depends on what driver you're using. For example, for most >> dvb-usb >> devices, this is given by the logic bellow: >> >> if (d->props.rc.legacy.rc_interval < 40) >> d->props.rc.legacy.rc_interval = 100; /* default */ >> >> input_dev->rep[REP_PERIOD] = d->props.rc.legacy.rc_interval; >> input_dev->rep[REP_DELAY] = d->props.rc.legacy.rc_interval + 150; >> >> where the rc_interval defined by device entry at the dvb usb drivers. > > Isn't that function only called for DVB_RC_LEGACY mode? I just picked one random piece of the code that covers several RC remotes (most dvb-usb drivers are still using the legacy mode). Similar code are there for other devices. > Maybe I wasn't clear, but I'm talking only about the devices handled by > rc-core. With just a few exceptions, the repeat period/delay that were there before porting to rc-core were maintained. There are space for adjustments, as we did on a few cases. Em 11-05-2011 22:53, Dmitry Torokhov escreveu: > On Wed, May 11, 2011 at 08:59:16PM +0300, Anssi Hannula wrote: >> >> I meant replacing the softrepeat with native repeat for such devices >> that have native repeats but no native release events: >> >> - keypress from device => keydown + keyup >> - repeat from device => keydown + keyup >> - repeat from device => keydown + keyup >> >> This is what e.g. ati_remote driver now does. >> >> Or alternatively >> >> - keypress from device => keydown >> - repeat from device => repeat >> - repeat from device => repeat >> - nothing for 250ms => keyup >> (doing it this way requires some extra handling in X server to stop its >> softrepeat from triggering, though, as previously noted) >> >> With either of these, if one holds down volumeup, the repeat works, and >> stops volumeup'ing immediately when user releases the button (as it is >> supposed to). >> > > Unfortunately this does not work for devices that do not have hardware > autorepeat and also stops users from adjusting autorepeat parameters to > their liking. Yes. A solution like the above would limit the usage. There are some remotes (like for example, the Hauppauge Grey remotes I have here) that a simple keypress generates, in general, up to 3 scancodes (the normal keypress and up to two "bounced" repeat keycodes). So, the software key delay also serves as a way to de-bounce the keypress. > It appears that the delay to check whether the key has been released is > too long (almost order of magnitude longer than our typical autorepeat > period). Yes, because, for example, with NEC and RC-5 protocols, one keystroke or one repeat event takes 110/114 ms to be transmitted. The delay actually varies from protocol to protocol, so it is possible to do some adjustments, based on the protocol type, but it is an order of magnitude longer than a keyboard or mouse. > I think we should increase the period for remotes (both in > kernel and in X, and also see if the release check delay can be made > shorter, like 50-100 ms. Some adjustments like that can be made, but they are device-driver specific. For example, some in-hardware IR decoders with KS007 micro-controller just removes all repeat keycodes and replace them with new keystrokes. There are some shipped remotes that don't support the RC-5 or NEC key repeat event. So, on those, if you keep a key pressed, you just receive the same scancode several times. The last time I double checked all remotes I have here, on all cases the auto-repeat logic were doing the right job, but I won't doubt that we need to add some additional adjustments for some boards/devices. Anssi, what's the hardware that you're using? 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
[PATCH] [media] rc: add locking to fix register/show race
When device_add is called in rc_register_device, the rc sysfs nodes show
up, and there's a window in which ir-keytable can be launched via udev
and trigger a show_protocols call, which runs without various rc_dev
fields filled in yet. Add some locking around registration and
store/show_protocols to prevent that from happening.
The problem manifests thusly:
[64692.957872] BUG: unable to handle kernel NULL pointer dereference at
0090
[64692.957878] IP: [] show_protocols+0x47/0xf1 [rc_core]
[64692.957890] PGD 19cfc7067 PUD 19cfc6067 PMD 0
[64692.957894] Oops: [#1] SMP
[64692.957897] last sysfs file:
/sys/devices/pci:00/:00:03.1/usb3/3-1/3-1:1.0/rc/rc2/protocols
[64692.957902] CPU 3
[64692.957903] Modules linked in: redrat3(+) ir_lirc_codec lirc_dev
ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder rc_hauppauge ir_nec
_decoder rc_core ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter
ip6_tables snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_mi
di_event snd_seq_midi_emul snd_emu10k1 snd_rawmidi snd_ac97_codec ac97_bus
snd_seq snd_pcm snd_seq_device snd_timer snd_page_alloc snd_util_mem pcsp
kr tg3 snd_hwdep emu10k1_gp snd amd64_edac_mod gameport edac_core soundcore
edac_mce_amd k8temp shpchp i2c_piix4 lm63 e100 mii uinput ipv6 raid0 rai
d1 ata_generic firewire_ohci pata_acpi firewire_core crc_itu_t sata_svw
pata_serverworks floppy radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core
[last unloaded: redrat3]
[64692.957949] [64692.957952] Pid: 12265, comm: ir-keytable Tainted: G MW
2.6.39-rc6+ #2 empty empty/TYAN Thunder K8HM S3892
[64692.957957] RIP: 0010:[] []
show_protocols+0x47/0xf1 [rc_core]
[64692.957962] RSP: 0018:880194509e38 EFLAGS: 00010202
[64692.957964] RAX: RBX: a036d1e0 RCX: a036a47a
[64692.957966] RDX: 88019a84d000 RSI: a036d1e0 RDI: 88019cf2f3f0
[64692.957969] RBP: 880194509e68 R08: 0002 R09:
[64692.957971] R10: 0002 R11: 1617 R12: 88019a84d000
[64692.957973] R13: 1000 R14: 8801944d2e38 R15: 88019ce5f190
[64692.957976] FS: 7f0a30c9a720() GS:88019fc0()
knlGS:
[64692.957979] CS: 0010 DS: ES: CR0: 80050033
[64692.957981] CR2: 0090 CR3: 00019a8e CR4: 06e0
[64692.957983] DR0: DR1: DR2:
[64692.957986] DR3: DR6: 0ff0 DR7: 0400
[64692.957989] Process ir-keytable (pid: 12265, threadinfo 880194508000,
task 88019a9fc720)
[64692.957991] Stack:
[64692.957992] 0002 a036d1e0 880194509f58
1000
[64692.957997] 8801944d2e38 88019ce5f190 880194509e98
8131484b
[64692.958001] 8118e923 810e9b2f 880194509e98
8801944d2e18
[64692.958005] Call Trace:
[64692.958014] [] dev_attr_show+0x27/0x4e
[64692.958014] [] ? sysfs_read_file+0x94/0x172
[64692.958014] [] ? __get_free_pages+0x16/0x52
[64692.958014] [] sysfs_read_file+0xbd/0x172
[64692.958014] [] vfs_read+0xac/0xf3
[64692.958014] [] ? fget_light+0x3a/0xa1
[64692.958014] [] sys_read+0x4d/0x74
[64692.958014] [] system_call_fastpath+0x16/0x1b
Its a bit difficult to reproduce, but I'm fairly confident this has
fixed the problem. At least, I haven't been able to reproduce it in a
few dozen load/unload cycles of the redrat3 driver I'm working on...
This was originally reported by an Ubuntu 11.04 user running their
2.6.38 kernel, so this should probably go to 2.6.38 stable as well. (I
don't have a Reported-by line to provide here, it was someone on #lirc
on freenode that pastebinned it, driver was mceusb in that case).
CC: sta...@kernel.org
Signed-off-by: Jarod Wilson
---
drivers/media/rc/rc-main.c | 47 ++-
include/media/rc-core.h|7 -
2 files changed, 46 insertions(+), 8 deletions(-)
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index 646d701..0497e06 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -748,6 +748,9 @@ static struct {
* it is trigged by reading /sys/class/rc/rc?/protocols.
* It returns the protocol names of supported protocols.
* Enabled protocols are printed in brackets.
+ *
+ * dev->lock is taken to guard against races between device
+ * registration, store_protocols and show_protocols.
*/
static ssize_t show_protocols(struct device *device,
struct device_attribute *mattr, char *buf)
@@ -761,6 +764,8 @@ static ssize_t show_protocols(struct device *device,
if (!dev)
return -EINVAL;
+ mutex_lock(&dev->lock);
+
if (dev->driver_type == RC_DRIVER_SCANCODE) {
enabled = dev->rc_map.rc_type;
allowed = dev->allowed_protos;
@@ -783,6 +788,9 @@ static ssize_t show_protocol
Re: IR remote control autorepeat / evdev
On Wed, May 11, 2011 at 08:59:16PM +0300, Anssi Hannula wrote: > > I meant replacing the softrepeat with native repeat for such devices > that have native repeats but no native release events: > > - keypress from device => keydown + keyup > - repeat from device => keydown + keyup > - repeat from device => keydown + keyup > > This is what e.g. ati_remote driver now does. > > Or alternatively > > - keypress from device => keydown > - repeat from device => repeat > - repeat from device => repeat > - nothing for 250ms => keyup > (doing it this way requires some extra handling in X server to stop its > softrepeat from triggering, though, as previously noted) > > With either of these, if one holds down volumeup, the repeat works, and > stops volumeup'ing immediately when user releases the button (as it is > supposed to). > Unfortunately this does not work for devices that do not have hardware autorepeat and also stops users from adjusting autorepeat parameters to their liking. It appears that the delay to check whether the key has been released is too long (almost order of magnitude longer than our typical autorepeat period). I think we should increase the period for remotes (both in kernel and in X, and also see if the release check delay can be made shorter, like 50-100 ms. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dvb-core/dvb_frontend.c: Synchronizing legacy and new tuning API
On 05/11/2011 08:34 PM, Bjørn Mork wrote: > I see in drivers/media/dvb/dvb-core/dvb_frontend.c that there is some > synchronization between the old and the new API. > > But it is incomplete: The new FE_GET_PROPERTY will report only cached > values, which is whatever the application has written and not the > actual tuned values like FE_GET_FRONTEND will. The problem is that > FE_GET_PROPERTY only will call fe->ops.get_property even for legacy > drivers. It could have fallen back to calling fe->ops.get_frontend > followed by a cache synchronization. > > Is this difference intentional (because it costs too much, doesn't > matter, or whatever)? Or should I prepare a patch for dvb_frontend.c? Please try the patches submitted for testing: http://www.mail-archive.com/linux-media@vger.kernel.org/msg31194.html 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: TT S2-3650CI problems with high-SR DVB-S2 transponders
I've just tried with the 2.6.38 kernel from the backports, and the lock fix only - result is the same, unusable output from device - too many discontinuities. Noone using the S2-3600 / 3650 on high-rate transponders? Any other Linux-supported USB DVB-S2 device with CI and high SR support? -- 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: ngene CI problems
On Monday 07 March 2011 14:50:02 Martin Vidovic wrote: > ... > - SEC device generates NULL packets (ad infinitum): > > When reading from SEC, NULL packets are read and interleaved with > expected packets. They can be even read with dd(1) when nobody is > writing to SEC and even when CAM is not ready. > ... I reworked the driver to strip those null packets. Please try http://linuxtv.org/hg/~endriss/ngene-octopus-test/raw-rev/f0dc4237ad08 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
[cron job] v4l-dvb daily build: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Wed May 11 19:00:31 CEST 2011 git hash:f9b51477fe540fb4c65a05027fdd6f2ecce4db3b gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: OK linux-git-armv5-davinci: OK linux-git-armv5-ixp: OK linux-git-armv5-omap2: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-x86_64: OK linux-2.6.31.12-i686: ERRORS 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.31.12-x86_64: ERRORS 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 spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.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
dvb-core/dvb_frontend.c: Synchronizing legacy and new tuning API
I see in drivers/media/dvb/dvb-core/dvb_frontend.c that there is some
synchronization between the old and the new API.
But it is incomplete: The new FE_GET_PROPERTY will report only cached
values, which is whatever the application has written and not the
actual tuned values like FE_GET_FRONTEND will. The problem is that
FE_GET_PROPERTY only will call fe->ops.get_property even for legacy
drivers. It could have fallen back to calling fe->ops.get_frontend
followed by a cache synchronization.
Is this difference intentional (because it costs too much, doesn't
matter, or whatever)? Or should I prepare a patch for dvb_frontend.c?
I made a small util comparing the two APIs, basically just doing
fd = open("/dev/dvb/adapter0/frontend0", O_RDONLY);
ioctl(fd, FE_GET_INFO, &fe_info);
ioctl(fd, FE_GET_FRONTEND, &fe_param);
ioctl(fd, FE_GET_PROPERTY, &dtv_props);
close(fd);
and pretty-printing some of the results from the three ioctl()s. It
reports typically something like this:
bjorn@canardo:~$ /tmp/dvb_fe_test /dev/dvb/adapter1/frontend0
== /dev/dvb/adapter1/frontend0 ==
name: Philips TDA10023 DVB-C
type: FE_QAM
== FE_GET_FRONTEND ==
frequency : 394013477
inversion : off (0)
symbol_rate : 690
fec_inner : FEC_NONE (0)
modulation: QAM_256 (5)
== FE_GET_PROPERTY ==
[17] DTV_DELIVERY_SYSTEM : SYS_DVBC_ANNEX_AC (1)
[03] DTV_FREQUENCY : 39400
[06] DTV_INVERSION : auto (2)
[08] DTV_SYMBOL_RATE : 690
[09] DTV_INNER_FEC : FEC_AUTO (9)
[04] DTV_MODULATION : QAM_256 (5)
[35] DTV_API_VERSION : 5.1
[05] DTV_BANDWIDTH_HZ: BANDWIDTH_AUTO (3)
Notice how FE_GET_PROPERTY returns "auto" settings for inversion and
inner_fec, while FE_GET_FRONTEND reports the actual values currently set
in the tuner. Also notice how the frequency differs.
It's not a big issue I believe, but I do find this a bit confusing as
two different apps using different APIs will report different settings.
Bjørn
--
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 remote control autorepeat / evdev
On 11.05.2011 19:51, Mauro Carvalho Chehab wrote: > Em 11-05-2011 18:33, Anssi Hannula escreveu: >> On 11.05.2011 07:46, Mauro Carvalho Chehab wrote: >>> Hi Anssi/Peter, >> >> Hi! >> >>> Em 10-05-2011 15:43, Anssi Hannula escreveu: On 10.05.2011 08:30, Peter Hutterer wrote: > On Tue, May 10, 2011 at 08:14:30AM +0300, Anssi Hannula wrote: >> On 10.05.2011 07:11, Peter Hutterer wrote: >>> On Sun, May 08, 2011 at 07:38:00AM +0300, Anssi Hannula wrote: Hi all! Most IR/RF remotes differ from normal keyboards in that they don't provide release events. They do provide native repeat events, though. Currently the Linux kernel RC/input subsystems provide a simulated autorepeat for remote controls (default delay 500ms, period 33ms), and X.org server ignores these events and generates its own autorepeat for them. The kernel RC subsystem provides a simulated release event when 250ms has passed since the last native event (repeat or non-repeat) was received from the device. This is problematic, since it causes lots of extra repeat events to be always sent (for up to 250ms) after the user has released the remote control button, which makes the remote quite uncomfortable to use. >>> >>> I got a bit confused reading this description. Does this mean that >>> remotes >>> usually send: >>> key press - repeat - repeat - ... - repeat - >>> where the silence indicates that the key has been released? Which the >>> kernel >>> after 250ms translates into a release event. >>> And the kernel discards the repeats and generates it's own on 500/33? >>> Do I get this right so far? >> >> Yes. >> >>> If so, I'm not sure how to avoid the 250ms delay since we have no >>> indication >>> from the hardware when the silence will stop, right? >> >> Yes. >> AFAICS what we need is to not use softrepeat for these devices and >> instead use the native repeats. The 250ms release delay could then be >> kept (as it wouldn't cause unwanted repeats anymore) or it could be made >> 0ms if that is deemed better. >> >> I listed some ways to do that below in my original post. >> >>> Note that the repeat delay and ratio are configurable per-device using >>> XKB, >>> so you could set up the 500/33 in X too. >>> >>> While 500/33 is good for keyboards, this is generally not good for remote >>> controllers. >> >> 500/33 is the one kernel uses for remotes. > > No. It actually depends on what driver you're using. For example, for most > dvb-usb > devices, this is given by the logic bellow: > > if (d->props.rc.legacy.rc_interval < 40) > d->props.rc.legacy.rc_interval = 100; /* default */ > > input_dev->rep[REP_PERIOD] = d->props.rc.legacy.rc_interval; > input_dev->rep[REP_DELAY] = d->props.rc.legacy.rc_interval + 150; > > where the rc_interval defined by device entry at the dvb usb drivers. Isn't that function only called for DVB_RC_LEGACY mode? Maybe I wasn't clear, but I'm talking only about the devices handled by rc-core. >>> The bit rate for IR transmissions are slow. So, one keypress can last up to >>> about >>> 110 ms[1]. That means that the maximum repeat rate for IR devices with such >>> protocol should be bellow than 10 keystrokes/sec. >>> >>> Also, the minimum initial delay for IR needs to be different on a few >>> hardware that >>> have a broken IR implementation. We default it to 500ms, but a few drivers >>> change it >>> to fit into some hardware constraits. So, a few kernel driver have some >>> tweaks of >>> repeat times, to be sure that the device will work properly. >>> >>> [1] http://www.sbprojects.com/knowledge/ir/nec.htm >>> >> It wouldn't make any difference with the actual issue which is >> "autorepeat happening after physical key released". >> >> I guess the reason this hasn't come up earlier is that the unified IR/RC >> subsystem in the linux kernel is still quite new. It definitely needs to >> be improved regarding this issue - just trying to figure out the best >> way to do it. >>> >>> The repeat events always generated troubles, as it basically depends on how >>> the hardware actually handles it. Some hardware decoders and some protocols >>> support repeat events, while others don't. There are even some remote >>> controllers >>> that, instead of generating repeat codes, they just generate multiple >>> keypresses. >>> >>> With the rc-core, we've unified the repeat treatment (yet, there are some >>> exceptions to the default way, for some devices where that uses broken >>> hardware >>> decoders). >>> > right. we used to have hardware repeats in X a few releases back. I think > 1.6 was the first one that shifted to pure software autorepeat. One of the > results we sa
Re: IR remote control autorepeat / evdev
Em 11-05-2011 18:33, Anssi Hannula escreveu: > On 11.05.2011 07:46, Mauro Carvalho Chehab wrote: >> Hi Anssi/Peter, > > Hi! > >> Em 10-05-2011 15:43, Anssi Hannula escreveu: >>> On 10.05.2011 08:30, Peter Hutterer wrote: On Tue, May 10, 2011 at 08:14:30AM +0300, Anssi Hannula wrote: > On 10.05.2011 07:11, Peter Hutterer wrote: >> On Sun, May 08, 2011 at 07:38:00AM +0300, Anssi Hannula wrote: >>> Hi all! >>> >>> Most IR/RF remotes differ from normal keyboards in that they don't >>> provide release events. They do provide native repeat events, though. >>> >>> Currently the Linux kernel RC/input subsystems provide a simulated >>> autorepeat for remote controls (default delay 500ms, period 33ms), and >>> X.org server ignores these events and generates its own autorepeat for >>> them. >>> >>> The kernel RC subsystem provides a simulated release event when 250ms >>> has passed since the last native event (repeat or non-repeat) was >>> received from the device. >>> >>> This is problematic, since it causes lots of extra repeat events to be >>> always sent (for up to 250ms) after the user has released the remote >>> control button, which makes the remote quite uncomfortable to use. >> >> I got a bit confused reading this description. Does this mean that >> remotes >> usually send: >> key press - repeat - repeat - ... - repeat - >> where the silence indicates that the key has been released? Which the >> kernel >> after 250ms translates into a release event. >> And the kernel discards the repeats and generates it's own on 500/33? >> Do I get this right so far? > > Yes. > >> If so, I'm not sure how to avoid the 250ms delay since we have no >> indication >> from the hardware when the silence will stop, right? > > Yes. > AFAICS what we need is to not use softrepeat for these devices and > instead use the native repeats. The 250ms release delay could then be > kept (as it wouldn't cause unwanted repeats anymore) or it could be made > 0ms if that is deemed better. > > I listed some ways to do that below in my original post. > >> Note that the repeat delay and ratio are configurable per-device using >> XKB, >> so you could set up the 500/33 in X too. >> >> While 500/33 is good for keyboards, this is generally not good for remote >> controllers. > > 500/33 is the one kernel uses for remotes. No. It actually depends on what driver you're using. For example, for most dvb-usb devices, this is given by the logic bellow: if (d->props.rc.legacy.rc_interval < 40) d->props.rc.legacy.rc_interval = 100; /* default */ input_dev->rep[REP_PERIOD] = d->props.rc.legacy.rc_interval; input_dev->rep[REP_DELAY] = d->props.rc.legacy.rc_interval + 150; where the rc_interval defined by device entry at the dvb usb drivers. > >> The bit rate for IR transmissions are slow. So, one keypress can last up to >> about >> 110 ms[1]. That means that the maximum repeat rate for IR devices with such >> protocol should be bellow than 10 keystrokes/sec. >> >> Also, the minimum initial delay for IR needs to be different on a few >> hardware that >> have a broken IR implementation. We default it to 500ms, but a few drivers >> change it >> to fit into some hardware constraits. So, a few kernel driver have some >> tweaks of >> repeat times, to be sure that the device will work properly. >> >> [1] http://www.sbprojects.com/knowledge/ir/nec.htm >> > It wouldn't make any difference with the actual issue which is > "autorepeat happening after physical key released". > > I guess the reason this hasn't come up earlier is that the unified IR/RC > subsystem in the linux kernel is still quite new. It definitely needs to > be improved regarding this issue - just trying to figure out the best > way to do it. >> >> The repeat events always generated troubles, as it basically depends on how >> the hardware actually handles it. Some hardware decoders and some protocols >> support repeat events, while others don't. There are even some remote >> controllers >> that, instead of generating repeat codes, they just generate multiple >> keypresses. >> >> With the rc-core, we've unified the repeat treatment (yet, there are some >> exceptions to the default way, for some devices where that uses broken >> hardware >> decoders). >> right. we used to have hardware repeats in X a few releases back. I think 1.6 was the first one that shifted to pure software autorepeat. One of the results we saw in the transition period was the clash of hw autorepeat (in X's input system, anything that comes out of the kernel counts as "hw") and software repeat. Integrating them back in is going to be a bit iffy, especially since you need the integration with XKB on each device,
AW: Remote control not working for Terratec Cinergy C (2.6.37 Mantis driver)
Hello, I've decided to rework my patch once again and send it to the list. It adds support for Remote-Control in the mantis driver and implements the new rc-API. The patch enables rc for the cards - vp1041 - vp2033 - vp2040 It's only tested with a Terratec Cinergy S2 HD Regards Chris I've reworked my patch using at home for > -Ursprüngliche Nachricht- > Von: linux-media-ow...@vger.kernel.org [mailto:linux-media- > ow...@vger.kernel.org] Im Auftrag von Adrian C. > Gesendet: Dienstag, 10. Mai 2011 23:30 > An: linux-media@vger.kernel.org > Betreff: Re: Remote control not working for Terratec Cinergy C (2.6.37 > Mantis driver) > > On Fri, 6 May 2011, Marko Ristola wrote: > > > The hardware device is active (it is enabled, messages are sent from > > the remote to the Kernel Mantis software driver. The bytes can be > > logged into /var/log/messages file. > > > > That's all the driver is designed to do at this point. > > It doesn't sound promising. Thanks for the update Marko. > > -- > Adrian C. (anrxc) | anrxc..sysphere.org | PGP ID: D20A0618 > PGP FP: 02A5 628A D8EE 2A93 996E 929F D5CB 31B7 D20A 0618 > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" > in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html mantis_ir.patch Description: Binary data
[PATCH 2/3 v5] v4l: Move s5p-fimc driver into Video capture devices
s5p-fimc now also implements a camera capture video node so move it under the "Video capture devices" kernel config menu. Also update the entry to reflect the driver's coverage of EXYNOS4 SoCs. Signed-off-by: Sylwester Nawrocki Signed-off-by: Kyungmin Park --- drivers/media/video/Kconfig | 19 +++ 1 files changed, 11 insertions(+), 8 deletions(-) diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index d61414e..a705493 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -934,6 +934,17 @@ config VIDEO_MX2 This is a v4l2 driver for the i.MX27 and the i.MX25 Camera Sensor Interface +config VIDEO_SAMSUNG_S5P_FIMC + tristate "Samsung S5P and EXYNOS4 camera host interface driver" + depends on VIDEO_DEV && VIDEO_V4L2 && PLAT_S5P + select VIDEOBUF2_DMA_CONTIG + select V4L2_MEM2MEM_DEV + ---help--- + This is a v4l2 driver for Samsung S5P and EXYNOS4 camera + host interface and video postprocessor. + + To compile this driver as a module, choose M here: the + module will be called s5p-fimc. # # USB Multimedia device configuration @@ -1029,13 +1040,5 @@ config VIDEO_MEM2MEM_TESTDEV This is a virtual test device for the memory-to-memory driver framework. -config VIDEO_SAMSUNG_S5P_FIMC - tristate "Samsung S5P FIMC (video postprocessor) driver" - depends on VIDEO_DEV && VIDEO_V4L2 && PLAT_S5P - select VIDEOBUF2_DMA_CONTIG - select V4L2_MEM2MEM_DEV - help - This is a v4l2 driver for the S5P camera interface - (video postprocessor) endif # V4L_MEM2MEM_DRIVERS -- 1.7.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
[PATCH 3/3 v5] v4l: Add v4l2 subdev driver for S5P/EXYNOS4 MIPI-CSI receivers
Add the subdev driver for the MIPI CSIS units available in S5P and
Exynos4 SoC series. This driver supports both CSIS0 and CSIS1
MIPI-CSI2 receivers.
The driver requires Runtime PM to be enabled for proper operation.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/video/Kconfig |9 +
drivers/media/video/s5p-fimc/Makefile|6 +-
drivers/media/video/s5p-fimc/mipi-csis.c | 722 ++
drivers/media/video/s5p-fimc/mipi-csis.h | 22 +
4 files changed, 757 insertions(+), 2 deletions(-)
create mode 100644 drivers/media/video/s5p-fimc/mipi-csis.c
create mode 100644 drivers/media/video/s5p-fimc/mipi-csis.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index a705493..9c701dd 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -946,6 +946,15 @@ config VIDEO_SAMSUNG_S5P_FIMC
To compile this driver as a module, choose M here: the
module will be called s5p-fimc.
+config VIDEO_S5P_MIPI_CSIS
+ tristate "Samsung S5P and EXYNOS4 MIPI CSI receiver driver"
+ depends on VIDEO_V4L2 && PM_RUNTIME && VIDEO_V4L2_SUBDEV_API
+ ---help---
+ This is a v4l2 driver for Samsung S5P/EXYNOS4 MIPI-CSI receiver.
+
+ To compile this driver as a module, choose M here: the
+ module will be called s5p-csis.
+
#
# USB Multimedia device configuration
#
diff --git a/drivers/media/video/s5p-fimc/Makefile
b/drivers/media/video/s5p-fimc/Makefile
index 7ea1b14..df6954a 100644
--- a/drivers/media/video/s5p-fimc/Makefile
+++ b/drivers/media/video/s5p-fimc/Makefile
@@ -1,3 +1,5 @@
+s5p-fimc-objs := fimc-core.o fimc-reg.o fimc-capture.o
+s5p-csis-objs := mipi-csis.o
-obj-$(CONFIG_VIDEO_SAMSUNG_S5P_FIMC) := s5p-fimc.o
-s5p-fimc-y := fimc-core.o fimc-reg.o fimc-capture.o
+obj-$(CONFIG_VIDEO_S5P_MIPI_CSIS) += s5p-csis.o
+obj-$(CONFIG_VIDEO_SAMSUNG_S5P_FIMC) += s5p-fimc.o
diff --git a/drivers/media/video/s5p-fimc/mipi-csis.c
b/drivers/media/video/s5p-fimc/mipi-csis.c
new file mode 100644
index 000..d50efcb
--- /dev/null
+++ b/drivers/media/video/s5p-fimc/mipi-csis.c
@@ -0,0 +1,722 @@
+/*
+ * Samsung S5P SoC series MIPI-CSI receiver driver
+ *
+ * Copyright (C) 2011 Samsung Electronics Co., Ltd.
+ * Contact: Sylwester Nawrocki,
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "mipi-csis.h"
+
+static int debug;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, "Debug level (0-1)");
+
+/* Register map definition */
+
+/* CSIS global control */
+#define S5PCSIS_CTRL 0x00
+#define S5PCSIS_CTRL_DPDN_DEFAULT (0 << 31)
+#define S5PCSIS_CTRL_DPDN_SWAP (1 << 31)
+#define S5PCSIS_CTRL_ALIGN_32BIT (1 << 20)
+#define S5PCSIS_CTRL_UPDATE_SHADOW (1 << 16)
+#define S5PCSIS_CTRL_WCLK_EXTCLK (1 << 8)
+#define S5PCSIS_CTRL_RESET (1 << 4)
+#define S5PCSIS_CTRL_ENABLE(1 << 0)
+
+/* D-PHY control */
+#define S5PCSIS_DPHYCTRL 0x04
+#define S5PCSIS_DPHYCTRL_HSS_MASK (0x1f << 27)
+#define S5PCSIS_DPHYCTRL_ENABLE(0x1f << 0)
+
+#define S5PCSIS_CONFIG 0x08
+#define S5PCSIS_CFG_FMT_YCBCR422_8BIT (0x1e << 2)
+#define S5PCSIS_CFG_FMT_RAW8 (0x2a << 2)
+#define S5PCSIS_CFG_FMT_RAW10 (0x2b << 2)
+#define S5PCSIS_CFG_FMT_RAW12 (0x2c << 2)
+/* User defined formats, x = 1...4 */
+#define S5PCSIS_CFG_FMT_USER(x)((0x30 + x - 1) << 2)
+#define S5PCSIS_CFG_FMT_MASK (0x3f << 2)
+#define S5PCSIS_CFG_NR_LANE_MASK 3
+
+/* Interrupt mask. */
+#define S5PCSIS_INTMSK 0x10
+#define S5PCSIS_INTMSK_EN_ALL 0xf03f
+#define S5PCSIS_INTSRC 0x14
+
+/* Pixel resolution */
+#define S5PCSIS_RESOL 0x2c
+#define CSIS_MAX_PIX_WIDTH 0x
+#define CSIS_MAX_PIX_HEIGHT0x
+
+enum {
+ CSIS_CLK_MUX,
+ CSIS_CLK_GATE,
+};
+
+static char *csi_clock_name[] = {
+ [CSIS_CLK_MUX] = "sclk_csis",
+ [CSIS_CLK_GATE] = "csis",
+};
+#define NUM_CSIS_CLOCKSARRAY_SIZE(csi_clock_name)
+
+enum {
+ ST_POWERED = 1,
+ ST_STREAMING= 2,
+ ST_SUSPENDED= 4,
+};
+
+/**
+ * struct csis_state - the driver's internal state data structure
+ * @lock: mutex serializing the subdev and power management operations,
+ *protecting the 'format' and 'flags' members
+ * @pads: CSIS pads array
+ * @sd: pointer to v4l2_subdev associated with CSIS device instance
+ * @pdev: pointer to a CSIS platform device
+ * @regs_res: requested I/O register m
Re: [alsa-devel] fm801: implement TEA575x tuner autodetection
At Tue, 10 May 2011 23:24:15 +0200,
Ondrej Zary wrote:
>
> Autodetect TEA575x tuner connection type during init. This allows tuner to
> work out-of-the box.
>
> tea575x_tuner module parameter remains functional to force tuner type.
>
> Tested with SF256-PCP and SF64-PCR.
>
> Signed-off-by: Ondrej Zary
Applied now. Thanks.
Takashi
>
> --- linux-2.6.39-rc2-/sound/pci/fm801.c 2011-05-10 22:31:45.0
> +0200
> +++ linux-2.6.39-rc2/sound/pci/fm801.c2011-05-10 23:21:42.0
> +0200
> @@ -53,7 +53,7 @@ static int enable[SNDRV_CARDS] = SNDRV_D
> /*
> * Enable TEA575x tuner
> *1 = MediaForte 256-PCS
> - *2 = MediaForte 256-PCPR
> + *2 = MediaForte 256-PCP
> *3 = MediaForte 64-PCR
> * 16 = setup tuner only (this is additional bit), i.e. SF64-PCR FM card
> * High 16-bits are video (radio) device number + 1
> @@ -67,7 +67,7 @@ MODULE_PARM_DESC(id, "ID string for the
> module_param_array(enable, bool, NULL, 0444);
> MODULE_PARM_DESC(enable, "Enable FM801 soundcard.");
> module_param_array(tea575x_tuner, int, NULL, 0444);
> -MODULE_PARM_DESC(tea575x_tuner, "TEA575x tuner access method (1 = SF256-PCS,
> 2=SF256-PCPR, 3=SF64-PCR, +16=tuner-only).");
> +MODULE_PARM_DESC(tea575x_tuner, "TEA575x tuner access method (0 = auto, 1 =
> SF256-PCS, 2=SF256-PCP, 3=SF64-PCR, 8=disable, +16=tuner-only).");
>
> #define TUNER_ONLY (1<<4)
> #define TUNER_TYPE_MASK (~TUNER_ONLY & 0x)
> @@ -720,12 +720,13 @@ static int __devinit snd_fm801_pcm(struc
> /* GPIO to TEA575x maps */
> struct snd_fm801_tea575x_gpio {
> u8 data, clk, wren, most;
> + char *name;
> };
>
> static struct snd_fm801_tea575x_gpio snd_fm801_tea575x_gpios[] = {
> - { .data = 1, .clk = 3, .wren = 2, .most = 0 }, /* SF256-PCS */
> - { .data = 1, .clk = 0, .wren = 2, .most = 3 }, /* SF256-PCP */
> - { .data = 2, .clk = 0, .wren = 1, .most = 3 }, /* SF64-PCR */
> + { .data = 1, .clk = 3, .wren = 2, .most = 0, .name = "SF256-PCS" },
> + { .data = 1, .clk = 0, .wren = 2, .most = 3, .name = "SF256-PCP" },
> + { .data = 2, .clk = 0, .wren = 1, .most = 3, .name = "SF64-PCR" },
> };
>
> static void snd_fm801_tea575x_set_pins(struct snd_tea575x *tea, u8 pins)
> @@ -1229,14 +1230,24 @@ static int __devinit snd_fm801_create(st
> snd_card_set_dev(card, &pci->dev);
>
> #ifdef TEA575X_RADIO
> + chip->tea.card = card;
> + chip->tea.freq_fixup = 10700;
> + chip->tea.private_data = chip;
> + chip->tea.ops = &snd_fm801_tea_ops;
> if ((tea575x_tuner & TUNER_TYPE_MASK) > 0 &&
> (tea575x_tuner & TUNER_TYPE_MASK) < 4) {
> - chip->tea.card = card;
> - chip->tea.freq_fixup = 10700;
> - chip->tea.private_data = chip;
> - chip->tea.ops = &snd_fm801_tea_ops;
> - snd_tea575x_init(&chip->tea);
> - }
> + if (snd_tea575x_init(&chip->tea))
> + snd_printk(KERN_ERR "TEA575x radio not found\n");
> + } else if ((tea575x_tuner & TUNER_TYPE_MASK) == 0)
> + /* autodetect tuner connection */
> + for (tea575x_tuner = 1; tea575x_tuner <= 3; tea575x_tuner++) {
> + chip->tea575x_tuner = tea575x_tuner;
> + if (!snd_tea575x_init(&chip->tea)) {
> + snd_printk(KERN_INFO "detected TEA575x radio
> type %s\n",
> + snd_fm801_tea575x_gpios[tea575x_tuner -
> 1].name);
> + break;
> + }
> + }
> #endif
>
> *rchip = chip;
>
>
> --
> Ondrej Zary
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
--
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 remote control autorepeat / evdev
On 11.05.2011 07:46, Mauro Carvalho Chehab wrote: > Hi Anssi/Peter, Hi! > Em 10-05-2011 15:43, Anssi Hannula escreveu: >> On 10.05.2011 08:30, Peter Hutterer wrote: >>> On Tue, May 10, 2011 at 08:14:30AM +0300, Anssi Hannula wrote: On 10.05.2011 07:11, Peter Hutterer wrote: > On Sun, May 08, 2011 at 07:38:00AM +0300, Anssi Hannula wrote: >> Hi all! >> >> Most IR/RF remotes differ from normal keyboards in that they don't >> provide release events. They do provide native repeat events, though. >> >> Currently the Linux kernel RC/input subsystems provide a simulated >> autorepeat for remote controls (default delay 500ms, period 33ms), and >> X.org server ignores these events and generates its own autorepeat for >> them. >> >> The kernel RC subsystem provides a simulated release event when 250ms >> has passed since the last native event (repeat or non-repeat) was >> received from the device. >> >> This is problematic, since it causes lots of extra repeat events to be >> always sent (for up to 250ms) after the user has released the remote >> control button, which makes the remote quite uncomfortable to use. > > I got a bit confused reading this description. Does this mean that remotes > usually send: > key press - repeat - repeat - ... - repeat - > where the silence indicates that the key has been released? Which the > kernel > after 250ms translates into a release event. > And the kernel discards the repeats and generates it's own on 500/33? > Do I get this right so far? Yes. > If so, I'm not sure how to avoid the 250ms delay since we have no > indication > from the hardware when the silence will stop, right? Yes. AFAICS what we need is to not use softrepeat for these devices and instead use the native repeats. The 250ms release delay could then be kept (as it wouldn't cause unwanted repeats anymore) or it could be made 0ms if that is deemed better. I listed some ways to do that below in my original post. > Note that the repeat delay and ratio are configurable per-device using > XKB, > so you could set up the 500/33 in X too. > > While 500/33 is good for keyboards, this is generally not good for remote > controllers. 500/33 is the one kernel uses for remotes. > The bit rate for IR transmissions are slow. So, one keypress can last up to > about > 110 ms[1]. That means that the maximum repeat rate for IR devices with such > protocol should be bellow than 10 keystrokes/sec. > > Also, the minimum initial delay for IR needs to be different on a few > hardware that > have a broken IR implementation. We default it to 500ms, but a few drivers > change it > to fit into some hardware constraits. So, a few kernel driver have some > tweaks of > repeat times, to be sure that the device will work properly. > > [1] http://www.sbprojects.com/knowledge/ir/nec.htm > It wouldn't make any difference with the actual issue which is "autorepeat happening after physical key released". I guess the reason this hasn't come up earlier is that the unified IR/RC subsystem in the linux kernel is still quite new. It definitely needs to be improved regarding this issue - just trying to figure out the best way to do it. > > The repeat events always generated troubles, as it basically depends on how > the hardware actually handles it. Some hardware decoders and some protocols > support repeat events, while others don't. There are even some remote > controllers > that, instead of generating repeat codes, they just generate multiple > keypresses. > > With the rc-core, we've unified the repeat treatment (yet, there are some > exceptions to the default way, for some devices where that uses broken > hardware > decoders). > >>> right. we used to have hardware repeats in X a few releases back. I think >>> 1.6 was the first one that shifted to pure software autorepeat. One of the >>> results we saw in the transition period was the clash of hw autorepeat (in >>> X's input system, anything that comes out of the kernel counts as "hw") and >>> software repeat. >>> >>> Integrating them back in is going to be a bit iffy, especially since you >>> need the integration with XKB on each device, essentially disallowing the >>> clients from enabling autorepeat. Not 100% what's required there. >>> The evtev part is going to be the simplest part of all that. >> >> I suspected it might be tricky. So maybe (at least for the time being) >> remote controls in X should simply get KeyRelease immediately after >> every KeyPress? > > This will probably cause some hurt. Things like volume control only work > nice on userspace if repeat events are properly handled. Hmm, maybe I'm missing something, but I was thinking that sending KeyRelease immediately *fixes* volume control. Currently (both on X and on standalone
[PATCH v5] Add v4l2 subdev driver for Samsung S5P MIPI-CSI receivers
Hello, this is fifth version of the subdev driver for MIPI-CSI2 receivers available on S5PVx10 and EXYNOS4 SoCs. This version is mainly to address Laurent's review comments, the full thread can be found here: https://patchwork.kernel.org/patch/725081/ This patch set also adds a V4L2_MBUS_FMT_JPEG_1X8 media bus format and moves the s5p-fimc driver to Video Capture Devices kconfig group. Changes since v4: - reworked set_fmt/get_fmt pad level ops - replaced readl/writel with s5pcsis_read/write macros - added initialization to default pixel format in s5pcsis_probe() - removed empty media pad ops - added missing __init attribute for s5pcsis_probe() - edited Kconfig descriptions for s5p-fimc and s5p-csis modules Patch 1/3 is unchanged since v4. Changes since v3: - slighty reworked the power management part - removed a reference counting in s_stream op as this should be handled on a media device and the pipeline level - s5p_csis_ prefix renamed to s5pcsis_ - updated the help text in Kconfig Changes since v2: - added reference counting in s_stream op to allow the mipi-csi subdev to be shared by multiple FIMC instances - added support for TRY format in pad get_fmt op - added pm_runtime* calls in s_stream op to avoid a need for explicit s_power(1) call - corrected locking around the pad ops, minor bug fixes Changes since v1: - added runtime PM support - conversion to the pad ops [PATCH 1/3] v4l: Add V4L2_MBUS_FMT_JPEG_1X8 media bus format [PATCH 2/3] v4l: Move s5p-fimc driver into Video capture devices [PATCH 3/3] v4l: Add v4l2 subdev driver for S5P/EXYNOS4 MIPI-CSI Documentation/DocBook/v4l/subdev-formats.xml | 46 ++ drivers/media/video/Kconfig | 28 +- drivers/media/video/s5p-fimc/Makefile|6 +- drivers/media/video/s5p-fimc/mipi-csis.c | 722 ++ drivers/media/video/s5p-fimc/mipi-csis.h | 22 + include/linux/v4l2-mediabus.h|3 + 6 files changed, 817 insertions(+), 10 deletions(-) -- 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
Re: IR remote control autorepeat / evdev
Hi Anssi/Peter, Em 10-05-2011 15:43, Anssi Hannula escreveu: > On 10.05.2011 08:30, Peter Hutterer wrote: >> On Tue, May 10, 2011 at 08:14:30AM +0300, Anssi Hannula wrote: >>> On 10.05.2011 07:11, Peter Hutterer wrote: On Sun, May 08, 2011 at 07:38:00AM +0300, Anssi Hannula wrote: > Hi all! > > Most IR/RF remotes differ from normal keyboards in that they don't > provide release events. They do provide native repeat events, though. > > Currently the Linux kernel RC/input subsystems provide a simulated > autorepeat for remote controls (default delay 500ms, period 33ms), and > X.org server ignores these events and generates its own autorepeat for > them. > > The kernel RC subsystem provides a simulated release event when 250ms > has passed since the last native event (repeat or non-repeat) was > received from the device. > > This is problematic, since it causes lots of extra repeat events to be > always sent (for up to 250ms) after the user has released the remote > control button, which makes the remote quite uncomfortable to use. I got a bit confused reading this description. Does this mean that remotes usually send: key press - repeat - repeat - ... - repeat - where the silence indicates that the key has been released? Which the kernel after 250ms translates into a release event. And the kernel discards the repeats and generates it's own on 500/33? Do I get this right so far? >>> >>> Yes. >>> If so, I'm not sure how to avoid the 250ms delay since we have no indication from the hardware when the silence will stop, right? >>> >>> Yes. >>> AFAICS what we need is to not use softrepeat for these devices and >>> instead use the native repeats. The 250ms release delay could then be >>> kept (as it wouldn't cause unwanted repeats anymore) or it could be made >>> 0ms if that is deemed better. >>> >>> I listed some ways to do that below in my original post. >>> Note that the repeat delay and ratio are configurable per-device using XKB, so you could set up the 500/33 in X too. While 500/33 is good for keyboards, this is generally not good for remote controllers. The bit rate for IR transmissions are slow. So, one keypress can last up to about 110 ms[1]. That means that the maximum repeat rate for IR devices with such protocol should be bellow than 10 keystrokes/sec. Also, the minimum initial delay for IR needs to be different on a few hardware that have a broken IR implementation. We default it to 500ms, but a few drivers change it to fit into some hardware constraits. So, a few kernel driver have some tweaks of repeat times, to be sure that the device will work properly. [1] http://www.sbprojects.com/knowledge/ir/nec.htm >>> It wouldn't make any difference with the actual issue which is >>> "autorepeat happening after physical key released". >>> >>> I guess the reason this hasn't come up earlier is that the unified IR/RC >>> subsystem in the linux kernel is still quite new. It definitely needs to >>> be improved regarding this issue - just trying to figure out the best >>> way to do it. The repeat events always generated troubles, as it basically depends on how the hardware actually handles it. Some hardware decoders and some protocols support repeat events, while others don't. There are even some remote controllers that, instead of generating repeat codes, they just generate multiple keypresses. With the rc-core, we've unified the repeat treatment (yet, there are some exceptions to the default way, for some devices where that uses broken hardware decoders). >> right. we used to have hardware repeats in X a few releases back. I think >> 1.6 was the first one that shifted to pure software autorepeat. One of the >> results we saw in the transition period was the clash of hw autorepeat (in >> X's input system, anything that comes out of the kernel counts as "hw") and >> software repeat. >> >> Integrating them back in is going to be a bit iffy, especially since you >> need the integration with XKB on each device, essentially disallowing the >> clients from enabling autorepeat. Not 100% what's required there. >> The evtev part is going to be the simplest part of all that. > > I suspected it might be tricky. So maybe (at least for the time being) > remote controls in X should simply get KeyRelease immediately after > every KeyPress? This will probably cause some hurt. Things like volume control only work nice on userspace if repeat events are properly handled. I think we should try to fix XKB/evdev to not use software events on remote controllers. It is easy to detect that an input device is a remote controller on evdev. I wrote a patch for it some time ago (unfortunately, hadn't time to finish it, as I got some jobs with higher priority). Peter, is that a way to pass a flag to XKB to say that a hw input device is not a keyboard, and need a different tr
Re: DVB nGene CI : TS Discontinuities issues
From: Ralph Metzler
> Issa Gorissen writes:
> > Could you please take a look at the cxd2099 issues ?
> >
> > I have attached a version with my changes. I have tested a lot of
> > different settings with the help of the chip datasheet.
> >
> > Scrambled programs are not handled correctly. I don't know if it is the
> > TICLK/MCLKI which is too high or something, or the sync detector ? Also,
> > as we have to set the TOCLK to max of 72MHz, there are way too much null
> > packets added. Is there a way to solve this ?
>
> I do not have any cxd2099 issues.
> I have a simple test program which includes a 32bit counter as payload
> and can pump data through the CI with full speed and have no packet
> loss. I only tested decoding with an ORF stream and an Alphacrypt CAM
> but also had no problems with this.
>
> Please take care not to write data faster than it is read. Starting two
> dds will not guarantee this. To be certain you could write a small
> program which never writes more packets than input buffer size minus
> the number of read packets (and minus the stuffing null packets on ngene).
>
> Before blaming packet loss on the CI data path also please make
> certain that you have no buffer overflows in the input part of
> the sec device.
> In the ngene driver you can e.g. add a printk in tsin_exchange():
>
> if (dvb_ringbuffer_free(&dev->tsin_rbuf) > len) {
> ...
> } else
> printk ("buffer overflow \n");
>
>
> Regards,
> Ralph
Ralph,
Please find my testing tool for the decryption attached. The idea is to write
5 packets and read them back from the CAM.
My input is a raw ts captured with a gnutv I modified with a demux filter of
0x2000. Gnutv outputs at dvr and dvbloop reads from it, process via sec0 and
writes output to a file.
The channel I selected has been decrypted. Only problem is I have artifacts in
the image and the sound.
Do you have any idea of what I should improve from my test tool to fix that
issue ?
Thx,
--
Issa
#include
#include
#include
#include
#include
#include
#include
#include
static void signal_handler(int _signal);
static int quit_app = 0;
int main(int argc, char *argv[])
{
signal(SIGINT, signal_handler);
if (argc <= 3)
exit(1);
int in_fd = open(argv[1], O_RDONLY);
int out_fd = open(argv[2], O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR);
int tsi_fd = open(argv[3], O_RDWR);
int rlen = 0;
int wlen = 0;
int rtsilen = 0;
int wtsilen = 0;
int BUFFY = 188 * 5;
unsigned char buf[BUFFY];
struct timespec sl[1];
sl[0].tv_nsec = 25;
while (!quit_app)
{
// read from input (DVR or other)
rlen = 0;
while (rlen < BUFFY) {
int i = read(in_fd, buf + rlen, BUFFY - rlen);
if (!i) {
quit_app = 1;
continue;
}
rlen += i;
}
// write data to caio device
wlen = write(tsi_fd, buf, rlen);
if (wlen != rlen)
{
perror("Did not write same amount of data from input to caio!!!");
exit(1);
}/* else
printf("written %d bytes in tsi\n", wlen);
*/
// read data from caio device - should be decrypted
// finding sync byte
do {
buf[0] = 0;
while (buf[0] != 0x47) {
rtsilen = read(tsi_fd, buf, 1);
}
if (buf[0] == 0x47) {
do {
int i = read(tsi_fd, buf + rtsilen, 188 - rtsilen);
rtsilen += i;
// printf("reading %d bytes from tsi\n", i);
} while (rtsilen < 188);
break;
}
} while (1);
//printf("sync byte found: %02x \n", buf[0]);
wtsilen = 0;
int nulls = 0;
do {
if (buf[0] == 0x47 && buf[1] == 0x1F && buf[2] == 0xFF) {
++nulls;
if (nulls > 100)
break;
//printf("null packet ");
// DVB null packet, discard
} else {
// printf("\nfrom tsi out: %x %x %x \n", buf[0], buf[1], buf[2]);
// write packet to output
int i = write(out_fd, buf, 188);
if (i < 188) {
perror("Did not write 188 bytes to output file!!!");
}
wtsilen += i;
}
if (rlen == wtsilen || quit_app)
break;
rtsilen = 0;
do {
rtsilen += read(tsi_fd, buf + rtsilen, 188 - rtsilen);
} while (rtsilen < 188);
} while (1);
}
close(in_fd);
close(out_fd);
close(tsi_fd);
exit(0);
}
static void signal_handler(int _signal)
{
if (!quit_app)
{
quit_app = 1;
}
}
Re: Current status report of mt9p031.
Hi Javier,
On Wednesday 11 May 2011 09:15:29 javier Martin wrote:
> On 11 May 2011 06:54, Chris Rodley wrote:
> > I am having a problem with these commands:
> >
> > root@chris:/home# ./media-ctl -r -l '"mt9p031 2-0048":0->"OMAP3 ISP CC
> >
> > DC":0[1], "OMAP3 ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]'
> > Resetting all links to inactive
> > Setting up link 16:0 -> 5:0 [1]
> > Setting up link 5:1 -> 6:0 [1]
> > root@chris:/home# ./media-ctl -f '"mt9p031 2-0048":0[SGRBG8 320x240],
> > "OMAP3 ISP CCDC":1[SGRBG8 320x240]'
> > Unable to parse format
>
> Hi Chris,
> you have to add SGRBG8 and SGRBG12 formats to media-ctl with the following
> patch:
>
> diff --git a/src/main.c b/src/main.c
> index 461dae1..fb1bfbe 100644
> --- a/src/main.c
> +++ b/src/main.c
> @@ -52,8 +52,10 @@ static struct {
> { "Y8", V4L2_MBUS_FMT_Y8_1X8},
> { "YUYV", V4L2_MBUS_FMT_YUYV8_1X16 },
> { "UYVY", V4L2_MBUS_FMT_UYVY8_1X16 },
> + { "SGRBG8", V4L2_MBUS_FMT_SGRBG8_1X8 },
> { "SGRBG10", V4L2_MBUS_FMT_SGRBG10_1X10 },
> { "SGRBG10_DPCM8", V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8 },
> + { "SGRBG12", V4L2_MBUS_FMT_SGRBG12_1X12 },
> };
>
> static const char *pixelcode_to_string(enum v4l2_mbus_pixelcode code)
Thanks for the patch. I've committed it to the media-ctl repository (with
additional Bayer formats).
--
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
[PATCH 1/2] v4l: Add M420 format definition
From: Hans de Goede
M420 is an hybrid YUV 4:2:2 packet/planar format. Two Y lines are
followed by an interleaved U/V line.
Signed-off-by: Hans de Goede
[laurent.pinch...@ideasonboard.com: split into v4l/uvcvideo patches]
Signed-off-by: Laurent Pinchart
---
include/linux/videodev2.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index a417270..8a4c309 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -336,6 +336,7 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_YUV420 v4l2_fourcc('Y', 'U', '1', '2') /* 12 YUV 4:2:0
*/
#define V4L2_PIX_FMT_HI240 v4l2_fourcc('H', 'I', '2', '4') /* 8 8-bit
color */
#define V4L2_PIX_FMT_HM12v4l2_fourcc('H', 'M', '1', '2') /* 8 YUV 4:2:0
16x16 macroblocks */
+#define V4L2_PIX_FMT_M420v4l2_fourcc('M', '4', '2', '0') /* 12 YUV 4:2:0
2 lines y, 1 line uv interleaved */
/* two planes -- one Y, one Cr + Cb interleaved */
#define V4L2_PIX_FMT_NV12v4l2_fourcc('N', 'V', '1', '2') /* 12 Y/CbCr
4:2:0 */
--
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
dvb demux: isolating the pids related to a scrambled channel
Hi, To decramble a channel with a ngene based card, you either need to: 1) send the full ts to sec0; 2) send a filtered ts to sec0. The latter case shall permit the descrambling of 2 channels transmitted from 2 different ts/tuners. I'm interested in knowing how to do this: filter a ts so that I only keep the needed pids for the cam. Can anyone help ? Thx -- Issa -- 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: DVB nGene CI : TS Discontinuities issues
> -Original Message-
> From: Issa Gorissen [mailto:flo...@usa.net]
> Sent: mercredi 11 mai 2011 15:13
> To: Ralph Metzler
> Cc: Linux Media Mailing List; S-bastien RAILLARD; Oliver Endriss
> Subject: Re: DVB nGene CI : TS Discontinuities issues
>
> From: Ralph Metzler
> > Issa Gorissen writes:
> > > Could you please take a look at the cxd2099 issues ?
> > >
> > > I have attached a version with my changes. I have tested a lot of
> > > different settings with the help of the chip datasheet.
> > >
> > > Scrambled programs are not handled correctly. I don't know if it is
> > the > TICLK/MCLKI which is too high or something, or the sync
> > detector ? Also, > as we have to set the TOCLK to max of 72MHz, there
> > are way too much null > packets added. Is there a way to solve this ?
> >
> > I do not have any cxd2099 issues.
> > I have a simple test program which includes a 32bit counter as payload
> > and can pump data through the CI with full speed and have no packet
> > loss. I only tested decoding with an ORF stream and an Alphacrypt CAM
> > but also had no problems with this.
> >
> > Please take care not to write data faster than it is read. Starting
> > two dds will not guarantee this. To be certain you could write a small
> > program which never writes more packets than input buffer size minus
> > the number of read packets (and minus the stuffing null packets on
> ngene).
> >
> > Before blaming packet loss on the CI data path also please make
> > certain that you have no buffer overflows in the input part of the sec
> > device.
> > In the ngene driver you can e.g. add a printk in tsin_exchange():
> >
> > if (dvb_ringbuffer_free(&dev->tsin_rbuf) > len) { ...
> > } else
> > printk ("buffer overflow \n");
> >
> >
> > Regards,
> > Ralph
>
>
> Ralph,
>
> Please find my testing tool for the decryption attached. The idea is to
> write
> 5 packets and read them back from the CAM.
>
> My input is a raw ts captured with a gnutv I modified with a demux
> filter of 0x2000. Gnutv outputs at dvr and dvbloop reads from it,
> process via sec0 and writes output to a file.
>
> The channel I selected has been decrypted. Only problem is I have
> artifacts in the image and the sound.
>
> Do you have any idea of what I should improve from my test tool to fix
> that issue ?
>
>
Good news, it seems that you managed to get it working!
You can check that your input and output TS files doesn't have issues or
discontinuities.
If you have access to a Windows running computer, you can test your TS files
with a small analyzer I wrote:
http://www.coexsi.fr/publications/mpegts-analyzer/
> Thx,
> --
> Issa
--
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] uvcvideo: Add M420 format support
From: Hans de Goede
The M420 format is used by the Microsoft LifeCam Studio HD.
Signed-off-by: Hans de Goede
[laurent.pinch...@ideasonboard.com: split into v4l/uvcvideo patches]
Signed-off-by: Laurent Pinchart
---
drivers/media/video/uvc/uvc_driver.c |5 +
drivers/media/video/uvc/uvcvideo.h |3 +++
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_driver.c
b/drivers/media/video/uvc/uvc_driver.c
index 496a9de..823f4b3 100644
--- a/drivers/media/video/uvc/uvc_driver.c
+++ b/drivers/media/video/uvc/uvc_driver.c
@@ -84,6 +84,11 @@ static struct uvc_format_desc uvc_fmts[] = {
.fcc= V4L2_PIX_FMT_YUV420,
},
{
+ .name = "YUV 4:2:0 (M420)",
+ .guid = UVC_GUID_FORMAT_M420,
+ .fcc= V4L2_PIX_FMT_M420,
+ },
+ {
.name = "YUV 4:2:2 (UYVY)",
.guid = UVC_GUID_FORMAT_UYVY,
.fcc= V4L2_PIX_FMT_UYVY,
diff --git a/drivers/media/video/uvc/uvcvideo.h
b/drivers/media/video/uvc/uvcvideo.h
index 0275613..7cf224b 100644
--- a/drivers/media/video/uvc/uvcvideo.h
+++ b/drivers/media/video/uvc/uvcvideo.h
@@ -172,6 +172,9 @@ struct uvc_xu_control {
#define UVC_GUID_FORMAT_RGBP \
{ 'R', 'G', 'B', 'P', 0x00, 0x00, 0x10, 0x00, \
0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
+#define UVC_GUID_FORMAT_M420 \
+ { 'M', '4', '2', '0', 0x00, 0x00, 0x10, 0x00, \
+0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
/*
* Driver specific constants.
--
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: why is there no enum_input in v4l2_subdev_video_ops
Hi Scott, On Wednesday 11 May 2011 10:43:30 Jiang, Scott wrote: > On Tue, May 10, 2011 at 5:51 PM, Laurent Pinchart wrote: > > On Tuesday 10 May 2011 08:14:10 Hans Verkuil wrote: > >> > On Tue, May 10, 2011 at 5:42 AM, Laurent Pinchart wrote: > >> >>> >> Why is there no enum_input operation in v4l2_subdev_video_ops? > >> >> > >> >> Why do you need one ? > >> > > >> > Because I want to query decoder how many inputs it can support. > >> > So the question is where we should store inputs info, board specific > >> > data or decoder driver? > >> > I appreciate your advice. > >> > >> ENUMINPUT as defined by V4L2 enumerates input connectors available on > >> the board. Which inputs the board designer hooked up is something that > >> only the top-level V4L driver will know. Subdevices do not have that > >> information, so enuminputs is not applicable there. > >> > >> Of course, subdevices do have input pins and output pins, but these are > >> assumed to be fixed. With the s_routing ops the top level driver selects > >> which input and output pins are active. Enumeration of those inputs and > >> outputs wouldn't gain you anything as far as I can tell since the > >> subdevice simply does not know which inputs/outputs are actually hooked > >> up. It's the top level driver that has that information (usually passed > >> in through board/card info structures). > > > > I agree. Subdevs don't have enough knowledge of their surroundings to > > make input enumeration really useful. They could enumerate their input > > pins, but not the inputs that are actually hooked up on board. > > > > The media controller framework is one way of solving this issue. It can > > report links for every input pad. > > > > Scott, can you tell us a bit more about the decoder you're working with ? > > What kind of system is it used in ? > > I'm working on ADV7183 and VS6624 connecting with blackfin through ppi. Enumerating inputs only matters for the ADV7183. The issue is that the adv7183 driver doesn't know how its inputs are routed on the board. I see several solutions to fix this issue. - Create an adv7183 platform data structure, and fill it in board code with input routing information. The adv7183 driver can use that information to implement a (to be added) enum_input operation. I don't really like this solution, as the adv7183 really shouldn't care about how video signals are routed on the board. - Pass the same information to the master v4l2_device driver that instantiates the adv7183. The information can then be used to implement the G_INPUT ioctl, or for internal purpose. You won't need any enum_input subdev operation in that case. - Use the media controller API to expose routing information to userspace. Like in the previous solution, board code would pass input routing information to the v4l2_device driver that would use use to create links. Links will then be enumerable and configurable by userspace. > By the way, ppi is a generic parallel interface, that means it can't know > the fmt supported itself. Should I use enum_mbus_fmt to ask decoder for > this info? > I found it in v4l2_subdev_video_ops, but didn't know its usage exactly. The enum_mbus_fmt can be used for that purpose, yes. You can use it to query the ADV7183 and VS6624 for their supported formats. You can also query the current format with g_mbus_fmt. If you want to implement the media controller API, you should go for the pad- level operations instead of enum_mbus_fmt/g_mbus_fmt (available in 2.6.39). -- 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
[PATCH 1/3 v5] v4l: Add V4L2_MBUS_FMT_JPEG_1X8 media bus format
Add V4L2_MBUS_FMT_JPEG_1X8 format and the corresponding Docbook
documentation.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
Acked-by: Laurent Pinchart
---
Documentation/DocBook/v4l/subdev-formats.xml | 46 ++
include/linux/v4l2-mediabus.h|3 ++
2 files changed, 49 insertions(+), 0 deletions(-)
diff --git a/Documentation/DocBook/v4l/subdev-formats.xml
b/Documentation/DocBook/v4l/subdev-formats.xml
index d7ccd25..a26b10c 100644
--- a/Documentation/DocBook/v4l/subdev-formats.xml
+++ b/Documentation/DocBook/v4l/subdev-formats.xml
@@ -2522,5 +2522,51 @@
+
+
+ JPEG Compressed Formats
+
+ Those data formats consist of an ordered sequence of 8-bit bytes
+ obtained from JPEG compression process. Additionally to the
+ _JPEG prefix the format code is made of
+ the following information.
+
+ The number of bus samples per entropy encoded
byte.
+ The bus width.
+
+
+ For instance, for a JPEG baseline process and an 8-bit bus width
+ the format will be named V4L2_MBUS_FMT_JPEG_1X8.
+
+
+
+ The following table lists existing JPEG compressed formats.
+
+
+ JPEG Formats
+
+
+
+
+
+
+ Identifier
+ Code
+ Remarks
+
+
+
+
+ V4L2_MBUS_FMT_JPEG_1X8
+ 0x4001
+ Besides of its usage for the parallel bus this format is
+ recommended for transmission of JPEG data over MIPI CSI bus
+ using the User Defined 8-bit Data types.
+
+
+
+
+
+
diff --git a/include/linux/v4l2-mediabus.h b/include/linux/v4l2-mediabus.h
index de5c159..5ea7f75 100644
--- a/include/linux/v4l2-mediabus.h
+++ b/include/linux/v4l2-mediabus.h
@@ -89,6 +89,9 @@ enum v4l2_mbus_pixelcode {
V4L2_MBUS_FMT_SGBRG12_1X12 = 0x3010,
V4L2_MBUS_FMT_SGRBG12_1X12 = 0x3011,
V4L2_MBUS_FMT_SRGGB12_1X12 = 0x3012,
+
+ /* JPEG compressed formats - next is 0x4002 */
+ V4L2_MBUS_FMT_JPEG_1X8 = 0x4001,
};
/**
--
1.7.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
RE: why is there no enum_input in v4l2_subdev_video_ops
Hi Laurent, On Tue, May 10, 2011 at 5:51 PM, Laurent Pinchart wrote: > Hi, > > On Tuesday 10 May 2011 08:14:10 Hans Verkuil wrote: >> > On Tue, May 10, 2011 at 5:42 AM, Laurent Pinchart wrote: >> >>> >> Why is there no enum_input operation in v4l2_subdev_video_ops? >> >> >> >> Why do you need one ? >> > >> > Because I want to query decoder how many inputs it can support. >> > So the question is where we should store inputs info, board specific data >> > or decoder driver? >> > I appreciate your advice. >> >> ENUMINPUT as defined by V4L2 enumerates input connectors available on the >> board. Which inputs the board designer hooked up is something that only >> the top-level V4L driver will know. Subdevices do not have that >> information, so enuminputs is not applicable there. >> >> Of course, subdevices do have input pins and output pins, but these are >> assumed to be fixed. With the s_routing ops the top level driver selects >> which input and output pins are active. Enumeration of those inputs and >> outputs wouldn't gain you anything as far as I can tell since the >> subdevice simply does not know which inputs/outputs are actually hooked >> up. It's the top level driver that has that information (usually passed in >> through board/card info structures). > > I agree. Subdevs don't have enough knowledge of their surroundings to make > input enumeration really useful. They could enumerate their input pins, but > not the inputs that are actually hooked up on board. > > The media controller framework is one way of solving this issue. It can report > links for every input pad. > > Scott, can you tell us a bit more about the decoder you're working with ? What > kind of system is it used in ? I'm working on ADV7183 and VS6624 connecting with blackfin through ppi. By the way, ppi is a generic parallel interface, that means it can't know the fmt supported itself. Should I use enum_mbus_fmt to ask decoder for this info? I found it in v4l2_subdev_video_ops, but didn't know its usage exactly. Regards, Scott -- 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: why is there no enum_input in v4l2_subdev_video_ops
Hi Laurent, On Tue, May 10, 2011 at 5:51 PM, Laurent Pinchart wrote: > Hi, > > On Tuesday 10 May 2011 08:14:10 Hans Verkuil wrote: >> > On Tue, May 10, 2011 at 5:42 AM, Laurent Pinchart wrote: >> >>> >> Why is there no enum_input operation in v4l2_subdev_video_ops? >> >> >> >> Why do you need one ? >> > >> > Because I want to query decoder how many inputs it can support. >> > So the question is where we should store inputs info, board specific data >> > or decoder driver? >> > I appreciate your advice. >> >> ENUMINPUT as defined by V4L2 enumerates input connectors available on the >> board. Which inputs the board designer hooked up is something that only >> the top-level V4L driver will know. Subdevices do not have that >> information, so enuminputs is not applicable there. >> >> Of course, subdevices do have input pins and output pins, but these are >> assumed to be fixed. With the s_routing ops the top level driver selects >> which input and output pins are active. Enumeration of those inputs and >> outputs wouldn't gain you anything as far as I can tell since the >> subdevice simply does not know which inputs/outputs are actually hooked >> up. It's the top level driver that has that information (usually passed in >> through board/card info structures). > > I agree. Subdevs don't have enough knowledge of their surroundings to make > input enumeration really useful. They could enumerate their input pins, but > not the inputs that are actually hooked up on board. > > The media controller framework is one way of solving this issue. It can report > links for every input pad. > > Scott, can you tell us a bit more about the decoder you're working with ? What > kind of system is it used in ? I'm working on ADV7183 and VS6624 connecting with blackfin through ppi. By the way, ppi is a generic parallel interface, that means it can't know the fmt supported itself. Should I use enum_mbus_fmt to ask decoder for this info? I found it in v4l2_subdev_video_ops, but didn't know its usage exactly. Regards, Scott -- 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
