Re: [git:v4l-dvb/v2.6.37] [media] radio-si4713: Add regulator framework support
Hi On Sun, 17 Oct 2010 22:34:32 +0200 Mauro Carvalho Chehab mche...@redhat.com wrote: This is an automatic generated email to let you know that the following patch were queued at the http://git.linuxtv.org/media_tree.git tree: Subject: [media] radio-si4713: Add regulator framework support Author: Jarkko Nikula jhnik...@gmail.com Date:Tue Sep 21 05:49:43 2010 -0300 Convert the driver to use regulator framework instead of set_power callback. This with gpio_reset platform data provide cleaner way to manage chip VIO, VDD and reset signal inside the driver. Signed-off-by: Jarkko Nikula jhnik...@gmail.com Cc: Eduardo Valentin eduardo.valen...@nokia.com Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com drivers/media/radio/si4713-i2c.c | 74 -- drivers/media/radio/si4713-i2c.h |5 ++- 2 files changed, 67 insertions(+), 12 deletions(-) --- http://git.linuxtv.org/media_tree.git?a=commitdiff;h=d455b639c1fb09f8ea888371fb6e04b490e115fb Was this patch lost somewhere? I don't see it in mainline for 2.6.37 but e.g. 85c55ef is there. -- Jarkko -- 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: Changing frame size on the fly in SOC module
Hi Guennadi, Thanks for the response, it's good just to get confirmation that I was indeed interpreting the code properly. I guess the main reason this is more significant for me is the constraints I have on the hardware, i.e. it cannot handle the 640x480 at any reasonable frame rate so we need the camera hardware to provide the smaller image and second closing the camera powers the module down to conserve power, which means time from open to image capture is slow (particularly because I have to drop the first few frames with the auto white balance etc... settles). I had already assumed that streaming would need to be stopped before the size could be changed, really don't see a problem with that. I had used that approach with non-SOC style modules. I think the documentation in videobuf talks about requesting the MAX buffer size you will require from the start. So again I had already assumed I'd need to do that as well. I'm not sure I fully understand the concern about multiple simultaneous users. I certainly don't have that as a user case in my own requirements (device is a small handheld teaching aid) and I would have thought that if 2 users try to use the same camera module at the same time all hell would probably break out anyway. Have to admit I've never tried it before. Adam -Original Message- From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de] Sent: 28 October 2010 20:01 To: Adam Sutton Cc: linux-media@vger.kernel.org Subject: Re: Changing frame size on the fly in SOC module Hi Adam On Thu, 28 Oct 2010, Adam Sutton wrote: Hi, Sometime ago I developed an SOC based camera driver for my platform (ov7675 on iMX25), for the most part it seems to be working well however at the time I couldn't manage to change the frame size on the fly (without closing / re-opening the device). The current problem I have is that my application needs to display a 320x240 preview image on screen, but to capture a static image at 640x480. I can do this as long as I close the device in between, unfortunately for power consumption reasons the camera device is put into a low power state whenever the device is released. This means that the image capture takes approx 1.5s (the requirement I have to meet is 1s). Now I could cheat and simply subsample (in software) the 640x480 image, but that puts additional burden on an already overworked MCU. Having been through the soc_camera and videobuf code and as far as I can tell this inability to change the frame size without closing the camera device appears to be a design decision. Yes, it is. What I'm really after is confirmation one way of the other. If it's not, what is the correct process to achieve the frame change without closing the device. And if it is, does anybody have any suggestions of possible workarounds? It has been decided that way, because we didn't have a good use-case for changing the frame format on-the-fly to develop for and to test with. You seem to have one now, so, go ahead;) There are a couple of issues to address though - videobuffer configuration is one of them, host reconfiguration is the other one, possible multiple simultaneous users is the third one (ok, only one of them will be actually streaming). This use case - different size preview and single shot capture has come up a couple of times before, but noone has brought it to a proper mainstream solution. One thing you'd still want to do, I think, is to stop streaming before reconfiguring, and restart it afterwards. So, maybe a viable solution would be: in soc_camera_s_fmt_vid_cap() check not just for icf-vb_vidq.bufs[0] != NULL, but rather for if streaming is not running, and then someone will certainly have to check for large enough buffers. So, you'd have to request max size buffers from the beginning even for preview. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ Plextek Limited Registered Address: London Road, Great Chesterford, Essex, CB10 1NY, UK Company Registration No. 2305889 VAT Registration No. GB 918 4425 15 Tel: +44 1799 533 200. Fax: +44 1799 533 201 Web:http://www.plextek.com Electronics Design and Consultancy -- 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: Changing frame size on the fly in SOC module
Hi Adam On Fri, 29 Oct 2010, Adam Sutton wrote: Hi Guennadi, Please, use the inline reply style. Thanks for the response, it's good just to get confirmation that I was indeed interpreting the code properly. I guess the main reason this is more significant for me is the constraints I have on the hardware, i.e. it cannot handle the 640x480 at any reasonable frame rate so we need the camera hardware to provide the smaller image and second closing the camera powers the module down to conserve power, which means time from open to image capture is slow (particularly because I have to drop the first few frames with the auto white balance etc... settles). I had already assumed that streaming would need to be stopped before the size could be changed, really don't see a problem with that. I had used that approach with non-SOC style modules. I think the documentation in videobuf talks about requesting the MAX buffer size you will require from the start. So again I had already assumed I'd need to do that as well. I'm not sure I fully understand the concern about multiple simultaneous users. I certainly don't have that as a user case in my own requirements (device is a small handheld teaching aid) and I would have thought that if 2 users try to use the same camera module at the same time all hell would probably break out anyway. Have to admit I've never tried it before. Multiple users, of which only one does the streaming. The rest may only issues control requests like adjusting image quality, etc. Thanks Guennadi Adam -Original Message- From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de] Sent: 28 October 2010 20:01 To: Adam Sutton Cc: linux-media@vger.kernel.org Subject: Re: Changing frame size on the fly in SOC module Hi Adam On Thu, 28 Oct 2010, Adam Sutton wrote: Hi, Sometime ago I developed an SOC based camera driver for my platform (ov7675 on iMX25), for the most part it seems to be working well however at the time I couldn't manage to change the frame size on the fly (without closing / re-opening the device). The current problem I have is that my application needs to display a 320x240 preview image on screen, but to capture a static image at 640x480. I can do this as long as I close the device in between, unfortunately for power consumption reasons the camera device is put into a low power state whenever the device is released. This means that the image capture takes approx 1.5s (the requirement I have to meet is 1s). Now I could cheat and simply subsample (in software) the 640x480 image, but that puts additional burden on an already overworked MCU. Having been through the soc_camera and videobuf code and as far as I can tell this inability to change the frame size without closing the camera device appears to be a design decision. Yes, it is. What I'm really after is confirmation one way of the other. If it's not, what is the correct process to achieve the frame change without closing the device. And if it is, does anybody have any suggestions of possible workarounds? It has been decided that way, because we didn't have a good use-case for changing the frame format on-the-fly to develop for and to test with. You seem to have one now, so, go ahead;) There are a couple of issues to address though - videobuffer configuration is one of them, host reconfiguration is the other one, possible multiple simultaneous users is the third one (ok, only one of them will be actually streaming). This use case - different size preview and single shot capture has come up a couple of times before, but noone has brought it to a proper mainstream solution. One thing you'd still want to do, I think, is to stop streaming before reconfiguring, and restart it afterwards. So, maybe a viable solution would be: in soc_camera_s_fmt_vid_cap() check not just for icf-vb_vidq.bufs[0] != NULL, but rather for if streaming is not running, and then someone will certainly have to check for large enough buffers. So, you'd have to request max size buffers from the beginning even for preview. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ Plextek Limited Registered Address: London Road, Great Chesterford, Essex, CB10 1NY, UK Company Registration No. 2305889 VAT Registration No. GB 918 4425 15 Tel: +44 1799 533 200. Fax: +44 1799 533 201 Web:http://www.plextek.com Electronics Design and Consultancy --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New channel frequencies for fr-Poitiers
Hi, Here is updated version of dvb frequencies init file for Poitiers - France. Damien ### start of contents Poitiers - Agglomération #R1 T 50600 8MHz AUTO NONE QAM64 8k AUTO NONE #R2 T 54600 8MHz AUTO NONE QAM64 8k AUTO NONE #R3 T 72200 8MHz AUTO NONE QAM64 8k AUTO NONE #R4 T 73800 8MHz AUTO NONE QAM64 8k AUTO NONE #R6 (no R5) T 75400 8MHz AUTO NONE QAM64 8k AUTO NONE ### end of contents -- 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
V4L2 and framebuffer for the same controller
Hi Guennadi, I find that your idea of provide a generic framebuffer driver that could sit on top of a v4l output driver, which may be a good solution of our LCD controller driver, or maybe much more other SOC LCD drivers. V4L2 interface support many features than framebuffer for video playback usage, such as buffer queue/dequeue, quality control, etc. However, framebuffer is common for UI display. Implement two drivers for one controller is a challenge for current architecture. I am interested in your idea. Could you elaborate it? Or do you think multifunction driver is the right solution for this the scenario? Jun -- 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: New media framework user space usage
Hello Laurant, With the media-ctl and yavta test applications, just run ./media-ctl -r -l 'mt9t001 3-005d:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' ./media-ctl -f 'mt9t001 3-005d:0[SGRBG10 1024x768], OMAP3 ISP CCDC:1[SGRBG10 1024x768]' ./yavta -f SGRBG10 -s 1024x768 -n 4 --capture=4 --skip 3 -F $(./media-ctl -e OMAP3 ISP CCDC output) Replace all occurences of 1024x768 by your sensor native resolution, and mt9t001 3-005d by the sensur subdev name. I did as you said and everything works fine until I use yavta: Video format set: width: 2952 height: 1944 buffer size: 11508480 Video format: BA10 (30314142) 2952x1944 4 buffers requested. length: 11508480 offset: 0 Buffer 0 mapped at address 0x4016d000. length: 11508480 offset: 11509760 Buffer 1 mapped at address 0x40c67000. length: 11508480 offset: 23019520 Buffer 2 mapped at address 0x41761000. length: 11508480 offset: 34529280 Buffer 3 mapped at address 0x4225b000. Unable to start streaming: 22 This is in ret = ioctl(dev-fd, enable ? VIDIOC_STREAMON : VIDIOC_STREAMOFF, type); errno 22 is: Invalid argument Any ideas where to look next? Thanks, Bastian -- 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
Webcam driver not working: drivers/media/video/gspca/ov519.c device 05a9:4519
Hi all, sorry for the noise, but in current mainline (2.6.36-git12) there are some updates in ov519.c I'm running this kernel now and my camera is still not working (tested in windows and it works). lsusb: Bus 008 Device 002: ID 05a9:4519 OmniVision Technologies, Inc. Webcam Classic But on the case it writes: GRANDTEC Grand IP CAMERA PRO Model: 2 In have an LAN or USB switch mode. Picture: http://tinypic.com/r/292llcg/7 Chips: 0705C07353 label on W9812G2GH-6 chip MX chip: T073520 29LV160CBTC-70G 2W417500 IC+ chip: IP101A LF 0731S15 FNS1877.1 The errors I get: Camorama Webcam Viewer: Could not connect to video device (/dev/video0). Please check connection. Cheese Webcam Booth: No device found. -- 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: New media framework user space usage
Hi, I did as you said and everything works fine until I use yavta: Video format set: width: 2952 height: 1944 buffer size: 11508480 Video format: BA10 (30314142) 2952x1944 ooops, I had a typo... 2952 becomes 2592 4 buffers requested. length: 11508480 offset: 0 Buffer 0 mapped at address 0x4016d000. length: 11508480 offset: 11509760 Buffer 1 mapped at address 0x40c67000. length: 11508480 offset: 23019520 Buffer 2 mapped at address 0x41761000. length: 11508480 offset: 34529280 Buffer 3 mapped at address 0x4225b000. Unable to start streaming: 22 This is in ret = ioctl(dev-fd, enable ? VIDIOC_STREAMON : VIDIOC_STREAMOFF, type); errno 22 is: Invalid argument Now it becomes Unable to start streaming: 32 : Broken pipe I will check if the video format of the sensor chip is SGRBG10 in default. cheers, Bastian Any ideas where to look next? Thanks, Bastian -- 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: Kworld usb 2800D audio
wow, I'm just glad you and other kernel devs take the time to figure all this out! -Tim On Thu, Oct 28, 2010 at 8:51 AM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Thu, Oct 28, 2010 at 10:48 AM, Tim Stowell stowe...@gmail.com wrote: Ah my bad, I need to read a little deeper it seems :) Thanks for the info, now I'll stop pulling my hair out trying to get non-existent audio. If it's any consolation, I had to rip one of the units apart and break out a scope to come to that conclusion. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New media framework user space usage
Hello, Now it becomes Unable to start streaming: 32 : Broken pipe I saw that my stub mt9p031_get_format gets called. Thanks a lot. So I reached the point where I can fill my driver with life. I will check if the video format of the sensor chip is SGRBG10 in default. I guess this is GRBG. What does the S stand for? Datasheet says: Pixels are output in a Bayer pattern format consisting of four “colors”—GreenR, GreenB, Red, and Blue (Gr, Gb, R, B)—representing three filter colors. When no mirror modes are enabled, the first row output alternates between Gr and R pixels, and the second row output alternates between B and Gb pixels. The Gr and Gb pixels have the same color filter, but they are treated as separate colors by the data path and analog signal chain. ciao, Bastian cheers, Bastian Any ideas where to look next? Thanks, Bastian -- 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: [RFC PATCH 0/2] Apple remote support
Em 29-10-2010 01:15, Jarod Wilson escreveu: On Thu, Oct 28, 2010 at 11:11:31PM -0400, Jarod Wilson wrote: I've got one of those tiny little 6-button Apple remotes here, now it can be decoded in-kernel (tested w/an mceusb transceiver). Oh yeah, RFC, because I'm not sure if we should have a more generic skip the checksum check support -- I seem to recall discussion about it in the not so recent past. And a decoder hack for one specific remote is just kinda ugly... Yeah, I have the same doubt. One possibility would be to simply report a 32 bits code, if the check fails. I don't doubt that we'll find other remotes with a NEC relaxed protocol, with no checksum at all. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git:v4l-dvb/v2.6.37] [media] radio-si4713: Add regulator framework support
Em 29-10-2010 04:29, Jarkko Nikula escreveu: Hi On Sun, 17 Oct 2010 22:34:32 +0200 Mauro Carvalho Chehab mche...@redhat.com wrote: This is an automatic generated email to let you know that the following patch were queued at the http://git.linuxtv.org/media_tree.git tree: Subject: [media] radio-si4713: Add regulator framework support Author: Jarkko Nikula jhnik...@gmail.com Date:Tue Sep 21 05:49:43 2010 -0300 Convert the driver to use regulator framework instead of set_power callback. This with gpio_reset platform data provide cleaner way to manage chip VIO, VDD and reset signal inside the driver. Signed-off-by: Jarkko Nikula jhnik...@gmail.com Cc: Eduardo Valentin eduardo.valen...@nokia.com Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com drivers/media/radio/si4713-i2c.c | 74 -- drivers/media/radio/si4713-i2c.h |5 ++- 2 files changed, 67 insertions(+), 12 deletions(-) --- http://git.linuxtv.org/media_tree.git?a=commitdiff;h=d455b639c1fb09f8ea888371fb6e04b490e115fb Was this patch lost somewhere? I don't see it in mainline for 2.6.37 but e.g. 85c55ef is there. I had to remove it from my queue, as the patch broke compilation: http://git.linuxtv.org/media_tree.git?a=commit;h=350df81ebaccc651fa4dfad27738db958e067ded What's the sense of adding a patch that breaks a driver? Even assuming that you would later send a patch fixing it, there are still some problems: 1) A latter patch will break git bisect; 2) A broken driver means that I can't test anymore if there are any other problems on other drivers. So, please test your patches against breakages, before sending them to me. Thanks, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New media framework user space usage
Hello Laurant, sorry I am flooding a bit here, but now I reached a point where I am really stuck. In the get_fmt_pad I set the following format *format = mt9p031-format; that is defined as mt9p031-format.code = V4L2_MBUS_FMT_SGRBG10_1X10; mt9p031-format.width = MT9P031_MAX_WIDTH; mt9p031-format.height = MT9P031_MAX_HEIGHT; mt9p031-format.field = V4L2_FIELD_NONE; mt9p031-format.colorspace = V4L2_COLORSPACE_SRGB; I found the different formats in /include/linux/v4l2-mediabus.h. I have 12 data bit channels, but there is no enum for that (like V4L2_MBUS_FMT_SGRBG10_1X12). I am the first guy needing a 12 bit-bus? Second thing is, the yavta app now gets stuck while dequeuing a buffer. strace ./yavta -f SGRBG10 -s 2592x1944 -n 4 --capture=4 --skip 3 -F /dev/video2 ... ioctl(3, VIDIOC_QBUF, 0xbec111cc) = 0 ioctl(3, VIDIOC_QBUF, 0xbec111cc) = 0 ioctl(3, VIDIOC_QBUF, 0xbec111cc) = 0 ioctl(3, VIDIOC_QBUF, 0xbec111cc) = 0 ioctl(3, VIDIOC_STREAMON, 0xbec11154) = 0 ioctl(3, VIDIOC_DQBUF strace gets stuck in mid of this line. cheers, Bastian -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git:v4l-dvb/v2.6.37] [media] radio-si4713: Add regulator framework support
On Fri, 29 Oct 2010 11:54:34 -0200 Mauro Carvalho Chehab mche...@redhat.com wrote: I had to remove it from my queue, as the patch broke compilation: http://git.linuxtv.org/media_tree.git?a=commit;h=350df81ebaccc651fa4dfad27738db958e067ded What's the sense of adding a patch that breaks a driver? Even assuming that you would later send a patch fixing it, there are still some problems: 1) A latter patch will break git bisect; 2) A broken driver means that I can't test anymore if there are any other problems on other drivers. So, please test your patches against breakages, before sending them to me. Oh shit, true, my fault. I definitely forgot one file from git commit but luckily I had the diff file around that I used in testing instead of the commit I sent... Sorry the hassle and thanks for letting me know, I'll send an update in a minute. -- Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] V4L/DVB: radio-si4713: Add regulator framework support
Convert the driver to use regulator framework instead of set_power callback.
This with gpio_reset platform data provide cleaner way to manage chip VIO,
VDD and reset signal inside the driver.
Signed-off-by: Jarkko Nikula jhnik...@gmail.com
Cc: Eduardo Valentin eduardo.valen...@nokia.com
---
v3:
include/media/si4713.h change was accidentally dropped from v2. Thanks to
Mauro Carvalho Chehab mche...@infradead.org for noticing.
v2:
I moved all the regulator management to i2c driver part of si4713 as suggested
by Eduardo. Then the si4713-i2c.c can still be used separately from
radio-si4713.c and it's easier to follow what supply voltages are needed.
v1:
I don't have specifications for this chip so I don't know how long the
reset signal must be active after power-up. I used 50 us from Maemo
kernel sources for Nokia N900 and I can successfully enable-disable
transmitter on N900 with vdd power cycling.
---
drivers/media/radio/si4713-i2c.c | 74 --
drivers/media/radio/si4713-i2c.h |5 ++-
include/media/si4713.h |3 +-
3 files changed, 68 insertions(+), 14 deletions(-)
diff --git a/drivers/media/radio/si4713-i2c.c b/drivers/media/radio/si4713-i2c.c
index a6e6f19..0fab6f8 100644
--- a/drivers/media/radio/si4713-i2c.c
+++ b/drivers/media/radio/si4713-i2c.c
@@ -27,6 +27,8 @@
#include linux/interrupt.h
#include linux/i2c.h
#include linux/slab.h
+#include linux/gpio.h
+#include linux/regulator/consumer.h
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
#include media/v4l2-common.h
@@ -43,6 +45,11 @@ MODULE_AUTHOR(Eduardo Valentin
eduardo.valen...@nokia.com);
MODULE_DESCRIPTION(I2C driver for Si4713 FM Radio Transmitter);
MODULE_VERSION(0.0.1);
+static const char *si4713_supply_names[SI4713_NUM_SUPPLIES] = {
+ vio,
+ vdd,
+};
+
#define DEFAULT_RDS_PI 0x00
#define DEFAULT_RDS_PTY0x00
#define DEFAULT_RDS_PS_NAME
@@ -369,7 +376,17 @@ static int si4713_powerup(struct si4713_device *sdev)
if (sdev-power_state)
return 0;
- sdev-platform_data-set_power(1);
+ err = regulator_bulk_enable(ARRAY_SIZE(sdev-supplies),
+ sdev-supplies);
+ if (err) {
+ v4l2_err(sdev-sd, Failed to enable supplies: %d\n, err);
+ return err;
+ }
+ if (gpio_is_valid(sdev-gpio_reset)) {
+ udelay(50);
+ gpio_set_value(sdev-gpio_reset, 1);
+ }
+
err = si4713_send_command(sdev, SI4713_CMD_POWER_UP,
args, ARRAY_SIZE(args),
resp, ARRAY_SIZE(resp),
@@ -384,7 +401,13 @@ static int si4713_powerup(struct si4713_device *sdev)
err = si4713_write_property(sdev, SI4713_GPO_IEN,
SI4713_STC_INT | SI4713_CTS);
} else {
- sdev-platform_data-set_power(0);
+ if (gpio_is_valid(sdev-gpio_reset))
+ gpio_set_value(sdev-gpio_reset, 0);
+ err = regulator_bulk_disable(ARRAY_SIZE(sdev-supplies),
+sdev-supplies);
+ if (err)
+ v4l2_err(sdev-sd,
+Failed to disable supplies: %d\n, err);
}
return err;
@@ -411,7 +434,13 @@ static int si4713_powerdown(struct si4713_device *sdev)
v4l2_dbg(1, debug, sdev-sd, Power down response: 0x%02x\n,
resp[0]);
v4l2_dbg(1, debug, sdev-sd, Device in reset mode\n);
- sdev-platform_data-set_power(0);
+ if (gpio_is_valid(sdev-gpio_reset))
+ gpio_set_value(sdev-gpio_reset, 0);
+ err = regulator_bulk_disable(ARRAY_SIZE(sdev-supplies),
+sdev-supplies);
+ if (err)
+ v4l2_err(sdev-sd,
+Failed to disable supplies: %d\n, err);
sdev-power_state = POWER_OFF;
}
@@ -1967,7 +1996,8 @@ static int si4713_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
struct si4713_device *sdev;
- int rval;
+ struct si4713_platform_data *pdata = client-dev.platform_data;
+ int rval, i;
sdev = kzalloc(sizeof *sdev, GFP_KERNEL);
if (!sdev) {
@@ -1976,11 +2006,26 @@ static int si4713_probe(struct i2c_client *client,
goto exit;
}
- sdev-platform_data = client-dev.platform_data;
- if (!sdev-platform_data) {
- v4l2_err(sdev-sd, No platform data registered.\n);
- rval = -ENODEV;
- goto free_sdev;
+ sdev-gpio_reset = -1;
+ if (pdata gpio_is_valid(pdata-gpio_reset)) {
+ rval =
Re: [RFC PATCH 0/2] Apple remote support
On Fri, Oct 29, 2010 at 11:46:02AM -0200, Mauro Carvalho Chehab wrote: Em 29-10-2010 01:15, Jarod Wilson escreveu: On Thu, Oct 28, 2010 at 11:11:31PM -0400, Jarod Wilson wrote: I've got one of those tiny little 6-button Apple remotes here, now it can be decoded in-kernel (tested w/an mceusb transceiver). Oh yeah, RFC, because I'm not sure if we should have a more generic skip the checksum check support -- I seem to recall discussion about it in the not so recent past. And a decoder hack for one specific remote is just kinda ugly... Yeah, I have the same doubt. One possibility would be to simply report a 32 bits code, if the check fails. I don't doubt that we'll find other remotes with a NEC relaxed protocol, with no checksum at all. So the Apple remotes do something funky... One of the four bytes is a remote identifier byte, which is used for pairing the remote to a specific device, and you can change the ID byte by simply holding down buttons on the remote. We could ignore the ID byte, and just match all Apple remotes, or we could add some sort of pairing support where we require the right ID byte in order to do scancode - keycode mapping... But in the match all case, I think we need the NEC extended scancode (e.g. 0xee8703 for KEY_MENU on my remote), while in the match paired case, we need the full 4-byte/32-bit code... Offhand, I'm not quite sure how to cleanly handle both cases. When using lirc, the full 32-bits are used, and you either have your config with exact matches (remote ID byte included), or you add an ignore mask, which tells scancode matching to just ignore the ID byte. -- Jarod Wilson ja...@redhat.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: [cron job] v4l-dvb daily build 2.6.26 and up: ERRORS
On Thursday, October 28, 2010 20:52:44 Mauro Carvalho Chehab wrote: Hi Jan, Em 28-10-2010 16:01, Jan Hoogenraad escreveu: Douglas: First of all thank you for the support you have done so far. Hans: Is it possible to build the tar from http://git.linuxtv.org/mchehab/new_build.git automatically each night, just like the way the hg archive was built ? I don't have sufficient processing power to run that. I haven't had time to look into new_build.git. It is on my todo list. I hope to have some time next week. Mauro: I'm willing to give the mercurial conversion a shot. I do not know a lot about v4l, but tend to be able to resolve this kind of release-type issues. The way it seems to me is that first new_build.git should compile for all releases that the hg archive supported. We still lack a maintainer for the new_build ;) I think we need to have someone with time looking on it, before flooding the ML's with breakage reports. I did the initial work: the tree is compiling, and I did a basic test with a few drivers on v2.6.32, but, unfortunately, I won't have time to maintain it. So, someone needs to head it. A few already talked to me about maintaining it it in priv, but didn't manifest yet publicly, because they're still analysing it. Also, so far, I received only one patch not made by me. Currently, the new_build tree covers kernel versions from .32 to .36, but, if nobody handles it, the backport patches will break with the time. Probably, some API will change on .37, requiring a new backport patch. In the meantime, someone may change one of the backported lines, breaking those patches. The good news is that there are just a few backport patches to maintain: 8 patches were enough for 2.6.32 (plus the v4l/compat.h logic). It is up to the one that takes the maintainership to decide what will be the minimum supported version. IMHO, 2.6.32 is a good choice, as it has a long-maintained stable version and almost all major distros are using it as basis for their newest version (and anyone 'crazy' enough to use an experimental, pre -rc version, is likely using a brand new distribution ;) ). I agree. I will kill the mercurial builds this weekend. After I have looked at new_build I'll see if I can set up an automated build for it (or at least do some prototyping). I'm not going to spend a lot of time on it as long as there is no maintainer. But once a maintainer is announced, then I will finish the work on the daily build so that it gets included every day. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- 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
[GIT PATCHES FOR 2.6.37] gspca for_2.6.37
The following changes since commit 18cb657ca1bafe635f368346a1676fb04c512edf: Merge branch 'stable/xen-pcifront-0.8.2' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen and branch 'for-linus' of git://xenbits.xen.org/people/sstabellini/linux-pvhvm (2010-10-28 17:11:17 -0700) are available in the git repository at: git://linuxtv.org/jfrancois/gspca.git for_2.6.37 Jean-François Moine (5): gspca - main: Version change gspca - main: Fix a small code error gspca - zc3xx: Bad clocksetting for mt9v111_3 with 640x480 resolution gspca - sonixj: Simplify and clarify the hv7131r probe function gspca: Convert some uppercase hexadecimal values to lowercase drivers/media/video/gspca/cpia1.c | 10 +- drivers/media/video/gspca/gspca.c |4 ++-- drivers/media/video/gspca/m5602/m5602_ov9650.c |2 +- drivers/media/video/gspca/pac207.c |4 ++-- drivers/media/video/gspca/sonixb.c |4 ++-- drivers/media/video/gspca/sonixj.c | 18 +- drivers/media/video/gspca/spca561.c|2 +- drivers/media/video/gspca/stv06xx/stv06xx.c|2 +- drivers/media/video/gspca/stv06xx/stv06xx_st6422.c |4 ++-- drivers/media/video/gspca/t613.c |2 +- drivers/media/video/gspca/tv8532.c |2 +- drivers/media/video/gspca/zc3xx.c |2 +- 12 files changed, 28 insertions(+), 28 deletions(-) -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: New media framework user space usage
On 10/29/2010 7:06 AM, Bastian Hecht wrote: Hello Laurant, sorry I am flooding a bit here, but now I reached a point where I am really stuck. In the get_fmt_pad I set the following format *format = mt9p031-format; that is defined as mt9p031-format.code = V4L2_MBUS_FMT_SGRBG10_1X10; mt9p031-format.width = MT9P031_MAX_WIDTH; mt9p031-format.height = MT9P031_MAX_HEIGHT; mt9p031-format.field = V4L2_FIELD_NONE; mt9p031-format.colorspace = V4L2_COLORSPACE_SRGB; I found the different formats in /include/linux/v4l2-mediabus.h. I have 12 data bit channels, but there is no enum for that (like V4L2_MBUS_FMT_SGRBG10_1X12). I am the first guy needing a 12 bit-bus? Most of the ISP can't handle more than 10-bit input - unless you're streaming raw sensor data straight to memory, you'll have to use the bridge lane shifter to decimate the input. In the new framework, I don't know how that's done, unfortunately. Also, technically, the mt9p031 output colorspace is not sRGB, although I'm not sure how close it is. It's its own sensor-specific space, determined by the color filters on it, and you'll want to calibrate for it at some point. Good luck, Eino-Ville Talvala Stanford University -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.26 and up: 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:Fri Oct 29 19:00:24 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 15167:abd3aac6644e git master: 3e6dce76d99b328716b43929b9195adfee1de00c git media-master: a348e9110ddb5d494e060d989b35dd1f35359d58 gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.32.6-armv5: WARNINGS linux-2.6.33-armv5: WARNINGS linux-2.6.34-armv5: WARNINGS linux-2.6.35.3-armv5: WARNINGS linux-2.6.32.6-armv5-davinci: ERRORS linux-2.6.33-armv5-davinci: ERRORS linux-2.6.34-armv5-davinci: ERRORS linux-2.6.35.3-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: ERRORS linux-2.6.33-armv5-ixp: ERRORS linux-2.6.34-armv5-ixp: ERRORS linux-2.6.35.3-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: ERRORS linux-2.6.33-armv5-omap2: ERRORS linux-2.6.34-armv5-omap2: ERRORS linux-2.6.35.3-armv5-omap2: ERRORS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.32.6-m32r: WARNINGS linux-2.6.33-m32r: WARNINGS linux-2.6.34-m32r: WARNINGS linux-2.6.35.3-m32r: WARNINGS linux-2.6.32.6-mips: WARNINGS linux-2.6.33-mips: WARNINGS linux-2.6.34-mips: WARNINGS linux-2.6.35.3-mips: WARNINGS linux-2.6.32.6-powerpc64: WARNINGS linux-2.6.33-powerpc64: WARNINGS linux-2.6.34-powerpc64: WARNINGS linux-2.6.35.3-powerpc64: WARNINGS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/7] rc-core: ir-core to rc-core conversion
This is my current patch queue, the main change is to make struct rc_dev the primary interface for rc drivers and to abstract away the fact that there's an input device lurking in there somewhere. The patchset has been updated to apply on top of the staging/for_v2.6.37-rc1 branch of the media_tree git repo. In addition, the cx88 and winbond-cir drivers are converted to use rc-core. The first patch (which is not to be merged) just merges the large scancodes patches for the input subsystem to make sure that merging my patches upstream will be doable post -rc1 (the input patches are already merged upstream). Given the changes, these patches touch every single driver. Obviously I haven't tested them all due to a lack of hardware (I have made sure that all drivers compile without any warnings and I have tested the end result on mceusb and winbond-cir hardware). --- David Härdeman (7): ir-core: dummy patch to base my work on top of Dmitry's large scancode work ir-core: convert drivers/media/video/cx88 to ir-core ir-core: remove remaining users of the ir-functions keyhandlers ir-core: more cleanups of ir-functions.c ir-core: merge and rename to rc-core ir-core: make struct rc_dev the primary interface rc-core: convert winbond-cir drivers/char/keyboard.c | 31 - drivers/input/evdev.c | 100 +- drivers/input/input.c | 192 ++- drivers/input/misc/Kconfig | 18 drivers/input/misc/Makefile |1 drivers/input/misc/winbond-cir.c| 1608 --- drivers/media/IR/Kconfig| 19 drivers/media/IR/Makefile |7 drivers/media/IR/ene_ir.c | 129 +- drivers/media/IR/ene_ir.h |3 drivers/media/IR/imon.c | 67 - drivers/media/IR/ir-core-priv.h | 26 drivers/media/IR/ir-functions.c | 254 drivers/media/IR/ir-jvc-decoder.c | 13 drivers/media/IR/ir-keytable.c | 577 -- drivers/media/IR/ir-lirc-codec.c| 121 +- drivers/media/IR/ir-nec-decoder.c | 15 drivers/media/IR/ir-raw-event.c | 382 -- drivers/media/IR/ir-rc5-decoder.c | 13 drivers/media/IR/ir-rc5-sz-decoder.c| 13 drivers/media/IR/ir-rc6-decoder.c | 17 drivers/media/IR/ir-sony-decoder.c | 11 drivers/media/IR/ir-sysfs.c | 362 -- drivers/media/IR/mceusb.c | 105 +- drivers/media/IR/nuvoton-cir.c | 85 + drivers/media/IR/nuvoton-cir.h |3 drivers/media/IR/rc-main.c | 1134 +++ drivers/media/IR/rc-map.c | 107 -- drivers/media/IR/rc-raw.c | 371 ++ drivers/media/IR/streamzap.c| 66 - drivers/media/IR/winbond-cir.c | 934 drivers/media/dvb/dm1105/Kconfig|3 drivers/media/dvb/dm1105/dm1105.c | 42 - drivers/media/dvb/dvb-usb/af9015.c | 16 drivers/media/dvb/dvb-usb/anysee.c |2 drivers/media/dvb/dvb-usb/dib0700.h |2 drivers/media/dvb/dvb-usb/dib0700_core.c|8 drivers/media/dvb/dvb-usb/dib0700_devices.c | 144 +- drivers/media/dvb/dvb-usb/dvb-usb-remote.c | 77 + drivers/media/dvb/dvb-usb/dvb-usb.h | 12 drivers/media/dvb/dvb-usb/lmedm04.c | 42 - drivers/media/dvb/mantis/mantis_common.h|4 drivers/media/dvb/mantis/mantis_input.c | 72 + drivers/media/dvb/siano/smscoreapi.c|2 drivers/media/dvb/siano/smsir.c | 52 - drivers/media/dvb/siano/smsir.h |3 drivers/media/dvb/ttpci/Kconfig |3 drivers/media/dvb/ttpci/budget-ci.c | 49 - drivers/media/video/Kconfig |2 drivers/media/video/bt8xx/Kconfig |4 drivers/media/video/bt8xx/bttv-input.c | 73 - drivers/media/video/bt8xx/bttvp.h |1 drivers/media/video/cx18/Kconfig|3 drivers/media/video/cx231xx/Kconfig |4 drivers/media/video/cx23885/cx23885-input.c | 64 + drivers/media/video/cx23885/cx23885.h |3 drivers/media/video/cx88/Kconfig|3 drivers/media/video/cx88/cx88-input.c | 233 +--- drivers/media/video/em28xx/Kconfig |4 drivers/media/video/em28xx/em28xx-input.c | 72 + drivers/media/video/ir-kbd-i2c.c| 28 drivers/media/video/ivtv/Kconfig|3 drivers/media/video/saa7134/Kconfig |2 drivers/media/video/saa7134/saa7134-input.c | 121 +- drivers/media/video/tlg2300/Kconfig |4 drivers/staging/cx25821/Kconfig |4 drivers/staging/go7007/Kconfig |4
[PATCH 1/7] ir-core: dummy patch to base my work on top of Dmitry's large scancode work
This patch adds the changes from Dmitry's large scancode work for the
input subsystem (the patches to the input core and to rc-core which were
accepted upstream). Not to be applied :)
Not-signed-off-by: Anyone
---
drivers/char/keyboard.c| 31 ++-
drivers/input/evdev.c | 100 --
drivers/input/input.c | 192 +++-
drivers/media/IR/ir-keytable.c | 393 +++-
include/linux/input.h | 55 --
include/media/rc-map.h |2
6 files changed, 555 insertions(+), 218 deletions(-)
diff --git a/drivers/char/keyboard.c b/drivers/char/keyboard.c
index a7ca752..e95d787 100644
--- a/drivers/char/keyboard.c
+++ b/drivers/char/keyboard.c
@@ -175,8 +175,7 @@ EXPORT_SYMBOL_GPL(unregister_keyboard_notifier);
*/
struct getset_keycode_data {
- unsigned int scancode;
- unsigned int keycode;
+ struct input_keymap_entry ke;
int error;
};
@@ -184,32 +183,50 @@ static int getkeycode_helper(struct input_handle *handle,
void *data)
{
struct getset_keycode_data *d = data;
- d-error = input_get_keycode(handle-dev, d-scancode, d-keycode);
+ d-error = input_get_keycode(handle-dev, d-ke);
return d-error == 0; /* stop as soon as we successfully get one */
}
int getkeycode(unsigned int scancode)
{
- struct getset_keycode_data d = { scancode, 0, -ENODEV };
+ struct getset_keycode_data d = {
+ .ke = {
+ .flags = 0,
+ .len= sizeof(scancode),
+ .keycode= 0,
+ },
+ .error = -ENODEV,
+ };
+
+ memcpy(d.ke.scancode, scancode, sizeof(scancode));
input_handler_for_each_handle(kbd_handler, d, getkeycode_helper);
- return d.error ?: d.keycode;
+ return d.error ?: d.ke.keycode;
}
static int setkeycode_helper(struct input_handle *handle, void *data)
{
struct getset_keycode_data *d = data;
- d-error = input_set_keycode(handle-dev, d-scancode, d-keycode);
+ d-error = input_set_keycode(handle-dev, d-ke);
return d-error == 0; /* stop as soon as we successfully set one */
}
int setkeycode(unsigned int scancode, unsigned int keycode)
{
- struct getset_keycode_data d = { scancode, keycode, -ENODEV };
+ struct getset_keycode_data d = {
+ .ke = {
+ .flags = 0,
+ .len= sizeof(scancode),
+ .keycode= keycode,
+ },
+ .error = -ENODEV,
+ };
+
+ memcpy(d.ke.scancode, scancode, sizeof(scancode));
input_handler_for_each_handle(kbd_handler, d, setkeycode_helper);
diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
index 9ddafc3..b9723c7 100644
--- a/drivers/input/evdev.c
+++ b/drivers/input/evdev.c
@@ -534,6 +534,80 @@ static int handle_eviocgbit(struct input_dev *dev,
}
#undef OLD_KEY_MAX
+static int evdev_handle_get_keycode(struct input_dev *dev,
+ void __user *p, size_t size)
+{
+ struct input_keymap_entry ke;
+ int error;
+
+ memset(ke, 0, sizeof(ke));
+
+ if (size == sizeof(unsigned int[2])) {
+ /* legacy case */
+ int __user *ip = (int __user *)p;
+
+ if (copy_from_user(ke.scancode, p, sizeof(unsigned int)))
+ return -EFAULT;
+
+ ke.len = sizeof(unsigned int);
+ ke.flags = 0;
+
+ error = input_get_keycode(dev, ke);
+ if (error)
+ return error;
+
+ if (put_user(ke.keycode, ip + 1))
+ return -EFAULT;
+
+ } else {
+ size = min(size, sizeof(ke));
+
+ if (copy_from_user(ke, p, size))
+ return -EFAULT;
+
+ error = input_get_keycode(dev, ke);
+ if (error)
+ return error;
+
+ if (copy_to_user(p, ke, size))
+ return -EFAULT;
+ }
+ return 0;
+}
+
+static int evdev_handle_set_keycode(struct input_dev *dev,
+ void __user *p, size_t size)
+{
+ struct input_keymap_entry ke;
+
+ memset(ke, 0, sizeof(ke));
+
+ if (size == sizeof(unsigned int[2])) {
+ /* legacy case */
+ int __user *ip = (int __user *)p;
+
+ if (copy_from_user(ke.scancode, p, sizeof(unsigned int)))
+ return -EFAULT;
+
+ if (get_user(ke.keycode, ip + 1))
+ return -EFAULT;
+
+ ke.len = sizeof(unsigned int);
+ ke.flags = 0;
+
+ } else {
+ size = min(size, sizeof(ke));
+
+ if (copy_from_user(ke, p, size))
+
[PATCH 2/7] ir-core: convert drivers/media/video/cx88 to ir-core
This patch converts the cx88 driver (for sampling hw) to use the
decoders provided by ir-core instead of the separate ones provided
by ir-functions (and gets rid of those).
The value for MO_DDS_IO had a comment saying it corresponded to
a 4kHz samplerate. That comment was unfortunately misleading. The
actual samplerate was something like 3250Hz.
The current value has been derived by analyzing the elapsed time
between interrupts for different values (knowing that each interrupt
corresponds to 32 samples).
Thanks to Mariusz Bialonczyk ma...@skyboo.net for testing my patches
(about one a day for two weeks!) on actual hardware.
Signed-off-by: David Härdeman da...@hardeman.nu
---
drivers/media/IR/ir-functions.c | 134 ---
drivers/media/video/cx88/Kconfig |2
drivers/media/video/cx88/cx88-input.c | 163 +++--
include/media/ir-common.h |3 -
4 files changed, 37 insertions(+), 265 deletions(-)
diff --git a/drivers/media/IR/ir-functions.c b/drivers/media/IR/ir-functions.c
index db591e4..f4c4115 100644
--- a/drivers/media/IR/ir-functions.c
+++ b/drivers/media/IR/ir-functions.c
@@ -111,140 +111,6 @@ u32 ir_extract_bits(u32 data, u32 mask)
}
EXPORT_SYMBOL_GPL(ir_extract_bits);
-static int inline getbit(u32 *samples, int bit)
-{
- return (samples[bit/32] (1 (31-(bit%32 ? 1 : 0;
-}
-
-/* sump raw samples for visual debugging ;) */
-int ir_dump_samples(u32 *samples, int count)
-{
- int i, bit, start;
-
- printk(KERN_DEBUG ir samples: );
- start = 0;
- for (i = 0; i count * 32; i++) {
- bit = getbit(samples,i);
- if (bit)
- start = 1;
- if (0 == start)
- continue;
- printk(%s, bit ? # : _);
- }
- printk(\n);
- return 0;
-}
-EXPORT_SYMBOL_GPL(ir_dump_samples);
-
-/* decode raw samples, pulse distance coding used by NEC remotes */
-int ir_decode_pulsedistance(u32 *samples, int count, int low, int high)
-{
- int i,last,bit,len;
- u32 curBit;
- u32 value;
-
- /* find start burst */
- for (i = len = 0; i count * 32; i++) {
- bit = getbit(samples,i);
- if (bit) {
- len++;
- } else {
- if (len = 29)
- break;
- len = 0;
- }
- }
-
- /* start burst to short */
- if (len 29)
- return 0x;
-
- /* find start silence */
- for (len = 0; i count * 32; i++) {
- bit = getbit(samples,i);
- if (bit) {
- break;
- } else {
- len++;
- }
- }
-
- /* silence to short */
- if (len 7)
- return 0x;
-
- /* go decoding */
- len = 0;
- last = 1;
- value = 0; curBit = 1;
- for (; i count * 32; i++) {
- bit = getbit(samples,i);
- if (last) {
- if(bit) {
- continue;
- } else {
- len = 1;
- }
- } else {
- if (bit) {
- if (len (low + high) /2)
- value |= curBit;
- curBit = 1;
- if (curBit == 1)
- break;
- } else {
- len++;
- }
- }
- last = bit;
- }
-
- return value;
-}
-EXPORT_SYMBOL_GPL(ir_decode_pulsedistance);
-
-/* decode raw samples, biphase coding, used by rc5 for example */
-int ir_decode_biphase(u32 *samples, int count, int low, int high)
-{
- int i,last,bit,len,flips;
- u32 value;
-
- /* find start bit (1) */
- for (i = 0; i 32; i++) {
- bit = getbit(samples,i);
- if (bit)
- break;
- }
-
- /* go decoding */
- len = 0;
- flips = 0;
- value = 1;
- for (; i count * 32; i++) {
- if (len high)
- break;
- if (flips 1)
- break;
- last = bit;
- bit = getbit(samples,i);
- if (last == bit) {
- len++;
- continue;
- }
- if (len low) {
- len++;
- flips++;
- continue;
- }
- value = 1;
- value |= bit;
- flips = 0;
- len = 1;
- }
- return value;
-}
-EXPORT_SYMBOL_GPL(ir_decode_biphase);
-
/* RC5 decoding
[PATCH 3/7] ir-core: remove remaining users of the ir-functions keyhandlers
This patch removes the remaining usages of the ir_input_nokey() and
ir_input_keydown() functions provided by drivers/media/IR/ir-functions.c
by using the corresponding functionality in ir-core instead.
Signed-off-by: David Härdeman da...@hardeman.nu
---
drivers/media/IR/imon.c |9 --
drivers/media/IR/ir-functions.c | 101 ++---
drivers/media/IR/ir-keytable.c | 110 ---
drivers/media/video/bt8xx/bttv-input.c | 32 ++--
drivers/media/video/bt8xx/bttvp.h |1
drivers/media/video/cx88/cx88-input.c | 11 ++-
drivers/media/video/ir-kbd-i2c.c|3 -
drivers/media/video/saa7134/saa7134-input.c | 49 ++--
drivers/staging/tm6000/tm6000-input.c | 15 +---
include/media/ir-common.h | 31 +---
include/media/ir-core.h |3 -
include/media/ir-kbd-i2c.h |4 -
12 files changed, 133 insertions(+), 236 deletions(-)
diff --git a/drivers/media/IR/imon.c b/drivers/media/IR/imon.c
index f782a9d..68699d4 100644
--- a/drivers/media/IR/imon.c
+++ b/drivers/media/IR/imon.c
@@ -1477,17 +1477,12 @@ static void imon_incoming_packet(struct imon_context
*ictx,
bool norelease = false;
int i;
u64 scancode;
- struct input_dev *rdev = NULL;
- struct ir_input_dev *irdev = NULL;
int press_type = 0;
int msec;
struct timeval t;
static struct timeval prev_time = { 0, 0 };
u8 ktype;
- rdev = ictx-rdev;
- irdev = input_get_drvdata(rdev);
-
/* filter out junk data on the older 0xffdc imon devices */
if ((buf[0] == 0xff) (buf[1] == 0xff) (buf[2] == 0xff))
return;
@@ -1568,9 +1563,9 @@ static void imon_incoming_packet(struct imon_context
*ictx,
if (ktype != IMON_KEY_PANEL) {
if (press_type == 0)
- ir_keyup(irdev);
+ ir_keyup(ictx-rdev);
else {
- ir_keydown(rdev, ictx-rc_scancode, ictx-rc_toggle);
+ ir_keydown(ictx-rdev, ictx-rc_scancode,
ictx-rc_toggle);
spin_lock_irqsave(ictx-kc_lock, flags);
ictx-last_keycode = ictx-kc;
spin_unlock_irqrestore(ictx-kc_lock, flags);
diff --git a/drivers/media/IR/ir-functions.c b/drivers/media/IR/ir-functions.c
index f4c4115..fca734c 100644
--- a/drivers/media/IR/ir-functions.c
+++ b/drivers/media/IR/ir-functions.c
@@ -1,7 +1,7 @@
/*
- *
- * some common structs and functions to handle infrared remotes via
- * input layer ...
+ * some common functions to handle infrared remote protocol decoding for
+ * drivers which have not yet been (or can't be) converted to use the
+ * regular protocol decoders...
*
* (c) 2003 Gerd Knorr kra...@bytesex.org [SuSE Labs]
*
@@ -31,67 +31,6 @@
MODULE_AUTHOR(Gerd Knorr kra...@bytesex.org [SuSE Labs]);
MODULE_LICENSE(GPL);
-static int repeat = 1;
-module_param(repeat, int, 0444);
-MODULE_PARM_DESC(repeat,auto-repeat for IR keys (default: on));
-
-/* --
*/
-
-static void ir_input_key_event(struct input_dev *dev, struct ir_input_state
*ir)
-{
- if (KEY_RESERVED == ir-keycode) {
- printk(KERN_INFO %s: unknown key: key=0x%02x down=%d\n,
- dev-name, ir-ir_key, ir-keypressed);
- return;
- }
- IR_dprintk(1,%s: key event code=%d down=%d\n,
- dev-name,ir-keycode,ir-keypressed);
- input_report_key(dev,ir-keycode,ir-keypressed);
- input_sync(dev);
-}
-
-/* --
*/
-
-int ir_input_init(struct input_dev *dev, struct ir_input_state *ir,
- const u64 ir_type)
-{
- ir-ir_type = ir_type;
-
- if (repeat)
- set_bit(EV_REP, dev-evbit);
-
- return 0;
-}
-EXPORT_SYMBOL_GPL(ir_input_init);
-
-
-void ir_input_nokey(struct input_dev *dev, struct ir_input_state *ir)
-{
- if (ir-keypressed) {
- ir-keypressed = 0;
- ir_input_key_event(dev,ir);
- }
-}
-EXPORT_SYMBOL_GPL(ir_input_nokey);
-
-void ir_input_keydown(struct input_dev *dev, struct ir_input_state *ir,
- u32 ir_key)
-{
- u32 keycode = ir_g_keycode_from_table(dev, ir_key);
-
- if (ir-keypressed ir-keycode != keycode) {
- ir-keypressed = 0;
- ir_input_key_event(dev,ir);
- }
- if (!ir-keypressed) {
- ir-ir_key = ir_key;
- ir-keycode = keycode;
- ir-keypressed = 1;
- ir_input_key_event(dev,ir);
- }
-}
-EXPORT_SYMBOL_GPL(ir_input_keydown);
-
/* --
*/
/* extract mask bits out of
[PATCH 4/7] ir-core: more cleanups of ir-functions.c
cx88 only depends on VIDEO_IR because it needs ir_extract_bits().
Move that function to ir-core.h and make it inline.
Lots of drivers had dependencies on VIDEO_IR when they really
wanted IR_CORE.
The only remaining drivers to depend on VIDEO_IR are bt8xx and
saa7134 (ir_rc5_timer_end is the only function exported by
ir-functions).
Rename VIDEO_IR - IR_LEGACY to give a hint to anyone writing or
converting drivers to IR_CORE that they do not want a dependency
on IR_LEGACY.
Signed-off-by: David Härdeman da...@hardeman.nu
---
drivers/media/IR/Kconfig |2 +-
drivers/media/IR/Makefile |2 +-
drivers/media/IR/ir-functions.c | 19 ---
drivers/media/dvb/dm1105/Kconfig |3 +--
drivers/media/dvb/ttpci/Kconfig |3 +--
drivers/media/video/Kconfig |2 +-
drivers/media/video/bt8xx/Kconfig |4 ++--
drivers/media/video/cx18/Kconfig |3 +--
drivers/media/video/cx231xx/Kconfig |4 ++--
drivers/media/video/cx88/Kconfig |3 +--
drivers/media/video/cx88/cx88-input.c |1 -
drivers/media/video/em28xx/Kconfig|4 ++--
drivers/media/video/ivtv/Kconfig |3 +--
drivers/media/video/saa7134/Kconfig |2 +-
drivers/media/video/tlg2300/Kconfig |4 ++--
drivers/staging/cx25821/Kconfig |4 ++--
drivers/staging/go7007/Kconfig|4 ++--
include/media/ir-common.h |1 -
include/media/ir-core.h | 19 +++
19 files changed, 40 insertions(+), 47 deletions(-)
diff --git a/drivers/media/IR/Kconfig b/drivers/media/IR/Kconfig
index aa4163e..20e02a0 100644
--- a/drivers/media/IR/Kconfig
+++ b/drivers/media/IR/Kconfig
@@ -10,7 +10,7 @@ menuconfig IR_CORE
if you don't need IR, as otherwise, you may not be able to
compile the driver for your adapter.
-config VIDEO_IR
+config IR_LEGACY
tristate
depends on IR_CORE
default IR_CORE
diff --git a/drivers/media/IR/Makefile b/drivers/media/IR/Makefile
index f9574ad..38873cf 100644
--- a/drivers/media/IR/Makefile
+++ b/drivers/media/IR/Makefile
@@ -4,7 +4,7 @@ ir-core-objs:= ir-keytable.o ir-sysfs.o ir-raw-event.o
rc-map.o
obj-y += keymaps/
obj-$(CONFIG_IR_CORE) += ir-core.o
-obj-$(CONFIG_VIDEO_IR) += ir-common.o
+obj-$(CONFIG_IR_LEGACY) += ir-common.o
obj-$(CONFIG_LIRC) += lirc_dev.o
obj-$(CONFIG_IR_NEC_DECODER) += ir-nec-decoder.o
obj-$(CONFIG_IR_RC5_DECODER) += ir-rc5-decoder.o
diff --git a/drivers/media/IR/ir-functions.c b/drivers/media/IR/ir-functions.c
index fca734c..ec021c9 100644
--- a/drivers/media/IR/ir-functions.c
+++ b/drivers/media/IR/ir-functions.c
@@ -31,25 +31,6 @@
MODULE_AUTHOR(Gerd Knorr kra...@bytesex.org [SuSE Labs]);
MODULE_LICENSE(GPL);
-/* --
*/
-/* extract mask bits out of data and pack them into the result */
-u32 ir_extract_bits(u32 data, u32 mask)
-{
- u32 vbit = 1, value = 0;
-
- do {
- if (mask1) {
- if (data1)
- value |= vbit;
- vbit=1;
- }
- data=1;
- } while (mask=1);
-
- return value;
-}
-EXPORT_SYMBOL_GPL(ir_extract_bits);
-
/* RC5 decoding stuff, moved from bttv-input.c to share it with
* saa7134 */
diff --git a/drivers/media/dvb/dm1105/Kconfig b/drivers/media/dvb/dm1105/Kconfig
index a6ceb08..576f3b7 100644
--- a/drivers/media/dvb/dm1105/Kconfig
+++ b/drivers/media/dvb/dm1105/Kconfig
@@ -1,7 +1,6 @@
config DVB_DM1105
tristate SDMC DM1105 based PCI cards
depends on DVB_CORE PCI I2C
- depends on INPUT
select DVB_PLL if !DVB_FE_CUSTOMISE
select DVB_STV0299 if !DVB_FE_CUSTOMISE
select DVB_STV0288 if !DVB_FE_CUSTOMISE
@@ -9,7 +8,7 @@ config DVB_DM1105
select DVB_CX24116 if !DVB_FE_CUSTOMISE
select DVB_SI21XX if !DVB_FE_CUSTOMISE
select DVB_DS3000 if !DVB_FE_CUSTOMISE
- depends on VIDEO_IR
+ depends on IR_CORE
help
Support for cards based on the SDMC DM1105 PCI chip like
DvbWorld 2002
diff --git a/drivers/media/dvb/ttpci/Kconfig b/drivers/media/dvb/ttpci/Kconfig
index debea8d..0ffd694 100644
--- a/drivers/media/dvb/ttpci/Kconfig
+++ b/drivers/media/dvb/ttpci/Kconfig
@@ -89,7 +89,6 @@ config DVB_BUDGET
config DVB_BUDGET_CI
tristate Budget cards with onboard CI connector
depends on DVB_BUDGET_CORE I2C
- depends on INPUT # due to IR
select DVB_STV0297 if !DVB_FE_CUSTOMISE
select DVB_STV0299 if !DVB_FE_CUSTOMISE
select DVB_TDA1004X if !DVB_FE_CUSTOMISE
@@ -98,7 +97,7 @@ config DVB_BUDGET_CI
select DVB_LNBP21 if !DVB_FE_CUSTOMISE
select DVB_TDA10023 if !DVB_FE_CUSTOMISE
select MEDIA_TUNER_TDA827X if !MEDIA_TUNER_CUSTOMISE
- depends on VIDEO_IR
+ depends on IR_CORE
help
Support for simple SAA7146 based DVB cards
Re: [RFC PATCH 0/2] Apple remote support
On Fri, Oct 29, 2010 at 11:11:41AM -0400, Jarod Wilson wrote: So the Apple remotes do something funky... One of the four bytes is a remote identifier byte, which is used for pairing the remote to a specific device, and you can change the ID byte by simply holding down buttons on the remote. How many different ID's are possible to set on the remote? We could ignore the ID byte, and just match all Apple remotes, or we could add some sort of pairing support where we require the right ID byte in order to do scancode - keycode mapping... But in the match all case, I think we need the NEC extended scancode (e.g. 0xee8703 for KEY_MENU on my remote), while in the match paired case, we need the full 4-byte/32-bit code... Offhand, I'm not quite sure how to cleanly handle both cases. If the number of possible ID values is not obscene, you could report the full 32 bit scancode and have a keymap with all the different variations. -- David Härdeman -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] mceusb: fix up reporting of trailing space
On Thu, Oct 28, 2010 at 11:08:10PM -0400, Jarod Wilson wrote: We were storing a bunch of spaces at the end of each signal, rather than a single long space. The in-kernel decoders were actually okay with this, but lirc isn't. Both are happy again with this change, which starts accumulating data upon seeing an 0x7f space, and then stores it when we see the next non-space, non-0x7f space, or an 0x80 end of signal command. To get to that final 0x80 properly, we also need to support proper parsing of 0x9f 0x01 commands, support for which is also added. I think the driver could be further simplified by using ir_raw_event_store_with_filter(), right? -- David Härdeman -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/2] Apple remote support
On Fri, Oct 29, 2010 at 09:17:11PM +0200, David Härdeman wrote: On Fri, Oct 29, 2010 at 11:11:41AM -0400, Jarod Wilson wrote: So the Apple remotes do something funky... One of the four bytes is a remote identifier byte, which is used for pairing the remote to a specific device, and you can change the ID byte by simply holding down buttons on the remote. How many different ID's are possible to set on the remote? 256, apparently. We could ignore the ID byte, and just match all Apple remotes, or we could add some sort of pairing support where we require the right ID byte in order to do scancode - keycode mapping... But in the match all case, I think we need the NEC extended scancode (e.g. 0xee8703 for KEY_MENU on my remote), while in the match paired case, we need the full 4-byte/32-bit code... Offhand, I'm not quite sure how to cleanly handle both cases. If the number of possible ID values is not obscene, you could report the full 32 bit scancode and have a keymap with all the different variations. I'm thinking 256 * 6 is probably a bit obscene, but I guess that way, you could work with all remotes if desired, and to pair, just remove all but the 6 for your remote... I'll keep giving it some thought, I feel like we ought to have a cleaner way to do this. -- Jarod Wilson ja...@redhat.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] mceusb: fix up reporting of trailing space
On Fri, Oct 29, 2010 at 09:21:21PM +0200, David Härdeman wrote: On Thu, Oct 28, 2010 at 11:08:10PM -0400, Jarod Wilson wrote: We were storing a bunch of spaces at the end of each signal, rather than a single long space. The in-kernel decoders were actually okay with this, but lirc isn't. Both are happy again with this change, which starts accumulating data upon seeing an 0x7f space, and then stores it when we see the next non-space, non-0x7f space, or an 0x80 end of signal command. To get to that final 0x80 properly, we also need to support proper parsing of 0x9f 0x01 commands, support for which is also added. I think the driver could be further simplified by using ir_raw_event_store_with_filter(), right? Hm, yeah, it probably would. Hadn't even thought to look at that. I'll give that a closer look... -- Jarod Wilson ja...@redhat.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/2] Apple remote support
On Fri, Oct 29, 2010 at 03:27:33PM -0400, Jarod Wilson wrote: On Fri, Oct 29, 2010 at 09:17:11PM +0200, David Härdeman wrote: On Fri, Oct 29, 2010 at 11:11:41AM -0400, Jarod Wilson wrote: So the Apple remotes do something funky... One of the four bytes is a remote identifier byte, which is used for pairing the remote to a specific device, and you can change the ID byte by simply holding down buttons on the remote. How many different ID's are possible to set on the remote? 256, apparently. Does the remote pick one for you at random? -- David Härdeman -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] support of GoTView PCI-E X5 3D Hybrid in cx23885
Hello,
I've added support of GoTView PCI-E X5 3D Hybrid to cx23885 module (thanks to
help of Gotview support team). Some details:
1. Everything initialize properly except radio.
2. All analog inputs (TV, composite, S-Video) are tested by myself in several
TV norms (SECAM-D, PAL, NTSC), everything work fine. DVB isn't tested properly
due to absense of DVB signal.
So the patch adds general support/detection of the card with working analog
part and hopefully working (untested) DVB part. I hope it will be useful.
Signed-off-by: Alexey Chernov 4er...@gmail.com
diff -uprB v4l-dvb.orig/drivers/media/video/cx23885/cx23885-cards.c
v4l-dvb/drivers/media/video/cx23885/cx23885-cards.c
--- v4l-dvb.orig/drivers/media/video/cx23885/cx23885-cards.c2010-10-28
22:04:10.0 +0400
+++ v4l-dvb/drivers/media/video/cx23885/cx23885-cards.c 2010-10-29
23:23:47.0 +0400
@@ -309,6 +309,24 @@ struct cx23885_board cx23885_boards[] =
CX25840_COMPONENT_ON,
} },
},
+ [CX23885_BOARD_GOTVIEW_X5_3D_HYBRID] = {
+ .name = GoTView X5 3D Hybrid,
+ .tuner_type = TUNER_XC5000,
+ .tuner_addr = 0x64,
+ .porta = CX23885_ANALOG_VIDEO,
+ .portb = CX23885_MPEG_DVB,
+ .input = {{
+ .type = CX23885_VMUX_TELEVISION,
+ .vmux = CX25840_VIN2_CH1 | CX25840_VIN5_CH2,
+ .gpio0 = 0x02,
+ }, {
+ .type = CX23885_VMUX_COMPOSITE1,
+ .vmux = CX23885_VMUX_COMPOSITE1,
+ }, {
+ .type = CX23885_VMUX_SVIDEO,
+ .vmux = CX25840_SVIDEO_LUMA3 |
CX25840_SVIDEO_CHROMA4,
+ } },
+ },
};
const unsigned int cx23885_bcount = ARRAY_SIZE(cx23885_boards);
@@ -496,6 +514,10 @@ struct cx23885_subid cx23885_subids[] =
.subvendor = 0x107d,
.subdevice = 0x6f22,
.card = CX23885_BOARD_LEADTEK_WINFAST_PXTV1200,
+ }, {
+ .subvendor = 0x5654,
+ .subdevice = 0x2390,
+ .card = CX23885_BOARD_GOTVIEW_X5_3D_HYBRID,
},
};
const unsigned int cx23885_idcount = ARRAY_SIZE(cx23885_subids);
@@ -712,6 +734,10 @@ int cx23885_tuner_callback(void *priv, i
else if (port-nr == 2)
bitmask = 0x04;
break;
+ case CX23885_BOARD_GOTVIEW_X5_3D_HYBRID:
+ /* Tuner Reset Command */
+ bitmask = 0x02;
+ break;
}
if (bitmask) {
@@ -1218,6 +1244,7 @@ void cx23885_card_setup(struct cx23885_d
case CX23885_BOARD_HAUPPAUGE_HVR1850:
case CX23885_BOARD_COMPRO_VIDEOMATE_E800:
case CX23885_BOARD_HAUPPAUGE_HVR1290:
+ case CX23885_BOARD_GOTVIEW_X5_3D_HYBRID:
default:
ts2-gen_ctrl_val = 0xc; /* Serial bus + punctured clock */
ts2-ts_clk_en_val = 0x1; /* Enable TS_CLK */
@@ -1245,6 +1272,7 @@ void cx23885_card_setup(struct cx23885_d
case CX23885_BOARD_MAGICPRO_PROHDTVE2:
case CX23885_BOARD_HAUPPAUGE_HVR1290:
case CX23885_BOARD_LEADTEK_WINFAST_PXTV1200:
+ case CX23885_BOARD_GOTVIEW_X5_3D_HYBRID:
dev-sd_cx25840 = v4l2_i2c_new_subdev(dev-v4l2_dev,
dev-i2c_bus[2].i2c_adap,
cx25840, cx25840, 0x88 1, NULL);
diff -uprB v4l-dvb.orig/drivers/media/video/cx23885/cx23885-dvb.c
v4l-dvb/drivers/media/video/cx23885/cx23885-dvb.c
--- v4l-dvb.orig/drivers/media/video/cx23885/cx23885-dvb.c 2010-10-28
22:04:10.0 +0400
+++ v4l-dvb/drivers/media/video/cx23885/cx23885-dvb.c 2010-10-29
23:24:53.0 +0400
@@ -460,6 +460,10 @@ static struct xc5000_config mygica_x8506
.if_khz = 5380,
};
+static struct zl10353_config gotview_x5_3d_hybrid_zl10353_config = {
+ .demod_address = 0x0F,
+};
+
static int cx23885_dvb_set_frontend(struct dvb_frontend *fe,
struct dvb_frontend_parameters *param)
{
@@ -484,6 +488,9 @@ static int cx23885_dvb_set_frontend(stru
/* Select Digital TV */
cx23885_gpio_set(dev, GPIO_0);
break;
+ case CX23885_BOARD_GOTVIEW_X5_3D_HYBRID:
+ cx23885_gpio_set(dev, GPIO_1);
+ break;
}
return 0;
}
@@ -966,6 +973,24 @@ static int dvb_register(struct cx23885_t
break;
}
break;
+ case CX23885_BOARD_GOTVIEW_X5_3D_HYBRID:
+ i2c_bus = dev-i2c_bus[port-nr - 1];
+
+ fe0-dvb.frontend = dvb_attach(zl10353_attach,
+ gotview_x5_3d_hybrid_zl10353_config,
+ i2c_bus-i2c_adap);
+
Re: [RFC PATCH 0/2] Apple remote support
On Fri, Oct 29, 2010 at 09:59:18PM +0200, David Härdeman wrote: On Fri, Oct 29, 2010 at 03:27:33PM -0400, Jarod Wilson wrote: On Fri, Oct 29, 2010 at 09:17:11PM +0200, David Härdeman wrote: On Fri, Oct 29, 2010 at 11:11:41AM -0400, Jarod Wilson wrote: So the Apple remotes do something funky... One of the four bytes is a remote identifier byte, which is used for pairing the remote to a specific device, and you can change the ID byte by simply holding down buttons on the remote. How many different ID's are possible to set on the remote? 256, apparently. Does the remote pick one for you at random? Looks like its randomly set at the factory, then holding a particular key combo on the remote for 5 seconds, you can cycle to another one. Not sure if another one means increment by one or randomly pick another one yet though. -- Jarod Wilson ja...@redhat.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] rc-core: ir-core to rc-core conversion
On Oct 29, 2010, at 3:07 PM, David Härdeman wrote: This is my current patch queue, the main change is to make struct rc_dev the primary interface for rc drivers and to abstract away the fact that there's an input device lurking in there somewhere. The patchset has been updated to apply on top of the staging/for_v2.6.37-rc1 branch of the media_tree git repo. In addition, the cx88 and winbond-cir drivers are converted to use rc-core. The first patch (which is not to be merged) just merges the large scancodes patches for the input subsystem to make sure that merging my patches upstream will be doable post -rc1 (the input patches are already merged upstream). Given the changes, these patches touch every single driver. Obviously I haven't tested them all due to a lack of hardware (I have made sure that all drivers compile without any warnings and I have tested the end result on mceusb and winbond-cir hardware). You can definitely sign me up for imon, streamzap and nuvoton-cir testing, and for sanity's sake, I can also verify multiple generations of mceusb devices. I'll see what I can get done on that front this weekend... -- 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: [PATCH 1/6] Input: add support for large scancodes
diff --git a/include/linux/input.h b/include/linux/input.h
index 7892651..0057698 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
snip
+/**
+ * struct input_keymap_entry - used by EVIOCGKEYCODE/EVIOCSKEYCODE ioctls
+ * @scancode: scancode represented in machine-endian form.
+ * @len: length of the scancode that resides in @scancode buffer.
+ * @index: index in the keymap, may be used instead of scancode
+ * @flags: allows to specify how kernel should handle the request. For
+ * example, setting INPUT_KEYMAP_BY_INDEX flag indicates that kernel
+ * should perform lookup in keymap by @index instead of @scancode
+ * @keycode: key code assigned to this scancode
+ *
+ * The structure is used to retrieve and modify keymap data. Users have
+ * option of performing lookup either by @scancode itself or by @index
+ * in keymap entry. EVIOCGKEYCODE will also return scancode or index
+ * (depending on which element was used to perform lookup).
+ */
+struct input_keymap_entry {
+#define INPUT_KEYMAP_BY_INDEX(1 0)
+ __u8 flags;
+ __u8 len;
+ __u16 index;
+ __u32 keycode;
+ __u8 scancode[32];
+};
I thought I better point out that this breaks make htmldocs (see below)
because of the '' characters in a kernel doc'd struct. This is with
12ba8d1e9262ce81a695795410bd9ee5c9407ba1 from Linus' tree (2.6.36). Moving
the #define below the struct works around the problem, but I guess the real
issue is in the kerneldoc code.
Cheers
James
$ make htmldocs
DOCPROC Documentation/DocBook/device-drivers.xml
HTMLDocumentation/DocBook/device-drivers.html
/home/james/src/kernel/linux-2.6/Documentation/DocBook/device-
drivers.xml:41883: parser error : StartTag: invalid element name
#define INPUT_KEYMAP_BY_INDEX (1 0)
^
/home/james/src/kernel/linux-2.6/Documentation/DocBook/device-
drivers.xml:41883: parser error : StartTag: invalid element name
#define INPUT_KEYMAP_BY_INDEX (1 0)
^
unable to parse /home/james/src/kernel/linux-2.6/Documentation/DocBook/device-
drivers.xml
/bin/cp: cannot stat `*.*htm*': No such file or directory
make[1]: *** [Documentation/DocBook/device-drivers.html] Error 1
make: *** [htmldocs] Error 2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] Input: add support for large scancodes
On Friday 29 October 2010 22:36:06 James Hogan wrote: I thought I better point out that this breaks make htmldocs (see below) because of the '' characters in a kernel doc'd struct. This is with 12ba8d1e9262ce81a695795410bd9ee5c9407ba1 from Linus' tree (2.6.36). Moving the #define below the struct works around the problem, but I guess the real issue is in the kerneldoc code. appologies for the noise. I see Randy had already beaten me to a fix. Cheers James -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: V4L/DVB/IR patches pending merge
2010/10/23 Mauro Carvalho Chehab mche...@redhat.com:
This is the list of patches that weren't applied yet. I've made a big effort
starting
last weekend to handle everything I could. All pull requests were addressed.
There are still
43 patches on my queue.
Please help me to clean the list.
This is what we have currently:
[snip]
== Waiting for Patrick Boettcher pboettc...@dibcom.fr review
==
May,25 2010: Adding support to the Geniatech/MyGica SBTVD Stick S870 remote
control http://patchwork.kernel.org/patch/102314 Hernán Ordiales
h.ordia...@gmail.com
Jul,14 2010: [1/4] drivers/media/dvb: Remove dead Configs
http://patchwork.kernel.org/patch/111972 Christian Dietrich
qy03f...@stud.informatik.uni-erlangen.de
Jul,14 2010: [2/4] drivers/media/dvb: Remove undead configs
http://patchwork.kernel.org/patch/111973 Christian Dietrich
qy03f...@stud.informatik.uni-erlangen.de
The first patch is probably broken.
Hernán,
Could you please re-generate it?
Yes, i'm sending it as attachment (regenerated agaisnt trunk, 15168 revision)
Cheers
--
Hernán
http://h.ordia.com.ar
# HG changeset patch
# User hordia
# Date 1288389936 10800
# Node ID 248f513cf5b8a8ecac08d13c90ddeeaf326c08ea
# Parent abd3aac6644e1a31020f4cdfdee84bde7ca1e1b4
Adding support to the Geniatech/MyGica SBTVD Stick S870 remote control (updated)
diff -r abd3aac6644e -r 248f513cf5b8 linux/drivers/media/dvb/dvb-usb/dib0700_core.c
--- a/linux/drivers/media/dvb/dvb-usb/dib0700_core.c Fri Jul 02 00:38:54 2010 -0300
+++ b/linux/drivers/media/dvb/dvb-usb/dib0700_core.c Fri Oct 29 19:05:36 2010 -0300
@@ -555,6 +555,14 @@
break;
}
break;
+ case 1:
+ /* Geniatech/MyGica remote protocol */
+ poll_reply.report_id = buf[0];
+ poll_reply.data_state = buf[1];
+ poll_reply.system = (buf[4] 8) | buf[4];
+ poll_reply.data = buf[5];
+ poll_reply.not_data = buf[4]; /* integrity check */
+ break;
default:
/* RC5 Protocol */
poll_reply.report_id = buf[0];
diff -r abd3aac6644e -r 248f513cf5b8 linux/drivers/media/dvb/dvb-usb/dib0700_devices.c
--- a/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c Fri Jul 02 00:38:54 2010 -0300
+++ b/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c Fri Oct 29 19:05:36 2010 -0300
@@ -831,6 +831,44 @@
{ 0x4540, KEY_RECORD }, /* Font 'Size' for Teletext */
{ 0x4541, KEY_SCREEN }, /* Full screen toggle, 'Hold' for Teletext */
{ 0x4542, KEY_SELECT }, /* Select video input, 'Select' for Teletext */
+
+ /* Key codes for the Geniatech/MyGica SBTVD Stick S870 remote
+ set dvb_usb_dib0700_ir_proto=1 */
+ { 0x38c7, KEY_TV }, /* TV/AV */
+ { 0x0cf3, KEY_POWER },
+ { 0x0af5, KEY_MUTE },
+ { 0x2bd4, KEY_VOLUMEUP },
+ { 0x2cd3, KEY_VOLUMEDOWN },
+ { 0x12ed, KEY_CHANNELUP },
+ { 0x13ec, KEY_CHANNELDOWN },
+ { 0x01fe, KEY_1 },
+ { 0x02fd, KEY_2 },
+ { 0x03fc, KEY_3 },
+ { 0x04fb, KEY_4 },
+ { 0x05fa, KEY_5 },
+ { 0x06f9, KEY_6 },
+ { 0x07f8, KEY_7 },
+ { 0x08f7, KEY_8 },
+ { 0x09f6, KEY_9 },
+ { 0x00ff, KEY_0 },
+ { 0x16e9, KEY_PAUSE },
+ { 0x17e8, KEY_PLAY },
+ { 0x0bf4, KEY_STOP },
+ { 0x26d9, KEY_REWIND },
+ { 0x27d8, KEY_FASTFORWARD },
+ { 0x29d6, KEY_ESC },
+ { 0x1fe0, KEY_RECORD },
+ { 0x20df, KEY_UP },
+ { 0x21de, KEY_DOWN },
+ { 0x11ee, KEY_LEFT },
+ { 0x10ef, KEY_RIGHT },
+ { 0x0df2, KEY_OK },
+ { 0x1ee1, KEY_PLAYPAUSE }, /* Timeshift */
+ { 0x0ef1, KEY_CAMERA }, /* Snapshot */
+ { 0x25da, KEY_EPG }, /* Info KEY_INFO */
+ { 0x2dd2, KEY_MENU }, /* DVD Menu */
+ { 0x0ff0, KEY_SCREEN }, /* Full screen toggle */
+ { 0x14eb, KEY_SHUFFLE },
};
/* STK7700P: Hauppauge Nova-T Stick, AVerMedia Volar */
Re: V4L/DVB/IR patches pending merge
On 10/30/2010 02:02 AM, Hernán Ordiales wrote: 2010/10/23 Mauro Carvalho Chehabmche...@redhat.com: This is the list of patches that weren't applied yet. I've made a big effort starting last weekend to handle everything I could. All pull requests were addressed. There are still 43 patches on my queue. Please help me to clean the list. This is what we have currently: [snip] == Waiting for Patrick Boettcherpboettc...@dibcom.fr review == May,25 2010: Adding support to the Geniatech/MyGica SBTVD Stick S870 remote control http://patchwork.kernel.org/patch/102314 Hernán Ordialesh.ordia...@gmail.com Jul,14 2010: [1/4] drivers/media/dvb: Remove dead Configs http://patchwork.kernel.org/patch/111972 Christian Dietrichqy03f...@stud.informatik.uni-erlangen.de Jul,14 2010: [2/4] drivers/media/dvb: Remove undead configs http://patchwork.kernel.org/patch/111973 Christian Dietrichqy03f...@stud.informatik.uni-erlangen.de The first patch is probably broken. Hernán, Could you please re-generate it? Yes, i'm sending it as attachment (regenerated agaisnt trunk, 15168 revision) Cheers Your keytable seems to be wrong since it have both keycode and its complement (which is used for error check normally). I think it is NEC remote? In that case address byte is typically same for all buttons. Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: V4L/DVB/IR patches pending merge
Em 29-10-2010 21:02, Hernán Ordiales escreveu: 2010/10/23 Mauro Carvalho Chehab mche...@redhat.com: This is the list of patches that weren't applied yet. I've made a big effort starting last weekend to handle everything I could. All pull requests were addressed. There are still 43 patches on my queue. Please help me to clean the list. This is what we have currently: [snip] == Waiting for Patrick Boettcher pboettc...@dibcom.fr review == May,25 2010: Adding support to the Geniatech/MyGica SBTVD Stick S870 remote control http://patchwork.kernel.org/patch/102314 Hernán Ordiales h.ordia...@gmail.com Jul,14 2010: [1/4] drivers/media/dvb: Remove dead Configs http://patchwork.kernel.org/patch/111972 Christian Dietrich qy03f...@stud.informatik.uni-erlangen.de Jul,14 2010: [2/4] drivers/media/dvb: Remove undead configs http://patchwork.kernel.org/patch/111973 Christian Dietrich qy03f...@stud.informatik.uni-erlangen.de The first patch is probably broken. Hernán, Could you please re-generate it? Yes, i'm sending it as attachment (regenerated agaisnt trunk, 15168 revision) Don't rebase against the mercurial tree. It is completely outdated. Use my git tree, instead: http://git.linuxtv.org/media_tree.git The IR should go to a separate file, and there's no need anymore to pass any parameter to the driver, as the IR table now specifies the protocol, and the driver automatically switches to NEC protocol, on devices using a NEC table. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: V4L/DVB/IR patches pending merge
On Fri, Oct 29, 2010 at 8:24 PM, Antti Palosaari cr...@iki.fi wrote:
On 10/30/2010 02:02 AM, Hernán Ordiales wrote:
2010/10/23 Mauro Carvalho Chehabmche...@redhat.com:
This is the list of patches that weren't applied yet. I've made a big
effort starting
last weekend to handle everything I could. All pull requests were
addressed. There are still
43 patches on my queue.
Please help me to clean the list.
This is what we have currently:
[snip]
== Waiting for Patrick Boettcherpboettc...@dibcom.fr
review ==
May,25 2010: Adding support to the Geniatech/MyGica SBTVD Stick S870
remote control http://patchwork.kernel.org/patch/102314 Hernán
Ordialesh.ordia...@gmail.com
Jul,14 2010: [1/4] drivers/media/dvb: Remove dead Configs
http://patchwork.kernel.org/patch/111972 Christian
Dietrichqy03f...@stud.informatik.uni-erlangen.de
Jul,14 2010: [2/4] drivers/media/dvb: Remove undead configs
http://patchwork.kernel.org/patch/111973 Christian
Dietrichqy03f...@stud.informatik.uni-erlangen.de
The first patch is probably broken.
Hernán,
Could you please re-generate it?
Yes, i'm sending it as attachment (regenerated agaisnt trunk, 15168
revision)
Cheers
Your keytable seems to be wrong since it have both keycode and its
complement (which is used for error check normally). I think it is NEC
remote? In that case address byte is typically same for all buttons.
Yes, i know the complement thing . The table was generated by reverse
engineering and i couldn't found the common address so i left in that
way. For example, for '7' button i receive:
dib0700: IR raw 01 01 00 00 07 F8 (len 6)
I think Is not a nec remote, it is a generic one that comes with
mygica/geniatech products. I rebuilt the key table (patch attached)
using '00' as address, is that ok? And leaving it using RC5 protocol
(instead adding a case for dvb_usb_dib0700_ir_proto=1)
in this way works ok too
. default:
. . /* RC5 Protocol */
. . poll_reply.report_id = buf[0];
. . poll_reply.data_state = buf[1];
. . poll_reply.system = (buf[2] 8) | buf[3];
. . poll_reply.data = buf[4];
. . poll_reply.not_data = buf[5];
. . break;
+ /* Key codes for the Geniatech/MyGica SBTVD Stick S870 remote
+ set dvb_usb_dib0700_ir_proto=1 */
+ { 0x0038, KEY_TV }, /* TV/AV */
+ { 0x000c, KEY_POWER },
+ { 0x000a, KEY_MUTE },
+ { 0x002b, KEY_VOLUMEUP },
+ { 0x002c, KEY_VOLUMEDOWN },
+ { 0x0012, KEY_CHANNELUP },
+ { 0x0013, KEY_CHANNELDOWN },
+ { 0x0001, KEY_1 },
+ { 0x0002, KEY_2 },
+ { 0x0003, KEY_3 },
+ { 0x0004, KEY_4 },
+ { 0x0005, KEY_5 },
+ { 0x0006, KEY_6 },
+ { 0x0007, KEY_7 },
+ { 0x0008, KEY_8 },
+ { 0x0009, KEY_9 },
+ { 0x, KEY_0 },
+ { 0x0016, KEY_PAUSE },
+ { 0x0017, KEY_PLAY },
+ { 0x000b, KEY_STOP },
+ { 0x0026, KEY_REWIND },
+ { 0x0027, KEY_FASTFORWARD },
+ { 0x0029, KEY_ESC },
+ { 0x001f, KEY_RECORD },
+ { 0x0020, KEY_UP },
+ { 0x0021, KEY_DOWN },
+ { 0x0011, KEY_LEFT },
+ { 0x0010, KEY_RIGHT },
+ { 0x000d, KEY_OK },
+ { 0x001e, KEY_PLAYPAUSE }, /* Timeshift */
+ { 0x000e, KEY_CAMERA }, /* Snapshot */
+ { 0x0025, KEY_EPG }, /* Info KEY_INFO */
+ { 0x002d, KEY_MENU }, /* DVD Menu */
+ { 0x000f, KEY_SCREEN }, /* Full screen toggle */
+ { 0x0014, KEY_SHUFFLE },
Antti
--
http://palosaari.fi/
--
Hernán
http://h.ordia.com.ar
# HG changeset patch
# User hordia
# Date 1288400129 10800
# Node ID b4c5259a13cd1a05af4ab5242236ad88f2de3319
# Parent abd3aac6644e1a31020f4cdfdee84bde7ca1e1b4
Geniatech/MyGica SBTVD Stick S870 remote control keytable
diff -r abd3aac6644e -r b4c5259a13cd linux/drivers/media/dvb/dvb-usb/dib0700_devices.c
--- a/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c Fri Jul 02 00:38:54 2010 -0300
+++ b/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c Fri Oct 29 21:55:29 2010 -0300
@@ -831,6 +831,44 @@
{ 0x4540, KEY_RECORD }, /* Font 'Size' for Teletext */
{ 0x4541, KEY_SCREEN }, /* Full screen toggle, 'Hold' for Teletext */
{ 0x4542, KEY_SELECT }, /* Select video input, 'Select' for Teletext */
+
+ /* Key codes for the Geniatech/MyGica SBTVD Stick S870 remote
+ set dvb_usb_dib0700_ir_proto=1 */
+ { 0x0038, KEY_TV }, /* TV/AV */
+ { 0x000c, KEY_POWER },
+ { 0x000a, KEY_MUTE },
+ { 0x002b, KEY_VOLUMEUP },
+ { 0x002c, KEY_VOLUMEDOWN },
+ { 0x0012, KEY_CHANNELUP },
+ { 0x0013, KEY_CHANNELDOWN },
+ { 0x0001, KEY_1 },
+ { 0x0002, KEY_2 },
+ { 0x0003, KEY_3 },
+ { 0x0004, KEY_4 },
+ { 0x0005, KEY_5 },
+ { 0x0006, KEY_6 },
+ { 0x0007, KEY_7 },
+ { 0x0008, KEY_8 },
+ { 0x0009, KEY_9 },
+ { 0x, KEY_0 },
+ { 0x0016, KEY_PAUSE },
+ { 0x0017, KEY_PLAY },
+ { 0x000b, KEY_STOP },
+ { 0x0026, KEY_REWIND },
+ { 0x0027, KEY_FASTFORWARD },
+ { 0x0029, KEY_ESC },
+ { 0x001f, KEY_RECORD },
+ { 0x0020, KEY_UP },
+ {
