- 22 Mar, 2011 40 commits
-
-
Guennadi Liakhovetski authored
The soc-camera core accesses the "pix" member of the struct v4l2_format::fmt union, which is only valid for V4L2_BUF_TYPE_VIDEO_CAPTURE streams. This patch adds explicit checks for this to {g,s,try}_fmt methods. Signed-off-by:Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com>
-
Sergio Aguirre authored
This fixes the problem in which a host driver sets a personalized sizeimage or bytesperline field, and gets ignored when doing G_FMT. Signed-off-by:
Sergio Aguirre <saaguirre@ti.com> Signed-off-by:
-
Jarod Wilson authored
The Apple and TiVo remotes I've got use an NEC-ish protocol, but rather than a command/not_command pair, they have what appear to be vendor ID bytes. This change makes the NEC decoder warn if the command/not_command checksum fails, but then passes along a full 32-bit scancode for keymap lookup. This change should make no difference for existing keymaps, since they simply won't have 32-bit scancodes, but allows for a 32-bit keymap. At the moment, that'll have to be uploaded by the user, but I've got Apple and TiVo remote keymaps forthcoming. In the long run (2.6.40, hopefully), we should probably just always use all 32 bits for all NEC keymaps, but this should get us by for 2.6.39. (Note that a few of the TiVo keys actuallly *do* pass the command checksum, so for now, the keymap for this remote will have to be a mix of 24-bit and 32-bit scancodes, but so be it). Signed-off-by:
Jarod Wilson <jarod@redhat.com> Signed-off-by:
-
Jarod Wilson authored
Signed-off-by:
-
Jarod Wilson authored
Give it a few tries, then exit. Prevents a possible endless loop situation. Signed-off-by:
-
Jarod Wilson authored
Both lirc_imon and lirc_sasem were causing gcc to complain about the possible use of uninitialized variables. Signed-off-by:
-
Jarod Wilson authored
The hdpvr's IR part, in short, sucks. As observed with a usb traffic sniffer, the Windows software for it uses a polling interval of 405ms. Its still not behaving as well as I'd like even with this change, but this inches us closer and closer to that point... Signed-off-by:
-
Jarod Wilson authored
The new hauppauge key tables use both device code button code. Signed-off-by:
-
Mauro Carvalho Chehab authored
This keymap were used for the Hauppauge Black remote controller only. It also contains some keycodes not found there. As the Hauppauge Black is now part of the hauppauge keymap, just remove it. Also, remove the modprobe hacks to select between the Gray and the Black versions of the remote controller as: - Both are supported by default by the keymap; - If the user just wants one keyboard supported, it is just a matter of changing the keymap via the userspace tool (ir-keytable), removing the keys that he doesn't desire. As ir-keytable auto-loads the keys via udev, this is better than obscure modprobe parameters. Signed-off-by:
-
Mauro Carvalho Chehab authored
The rc-hauppauge-new map is a messy thing, as it bundles 3 different remote controllers as if they were just one, discarding the address byte. Also, some key maps are wrong. With the conversion to the new rc-core, it is likely that most of the devices won't be working properly, as the i2c driver and the raw decoders are now providing 16 bits for the remote, instead of just 8. delete mode 100644 drivers/media/rc/keymaps/rc-hauppauge-new.c Signed-off-by:
-
Mauro Carvalho Chehab authored
There are two "hauppauge-new" keymaps, one with protocol unknown, and the other with the protocol marked accordingly. However, both tables are miss-named. Also, the old rc-hauppauge-new is broken, as it mixes three different controllers as if they were just one. This patch solves half of the problem by renaming the correct keycode table as just rc-hauppauge. This table contains the codes for the four different types of remote controllers found on Hauppauge cards, properly mapped with their different addresses. create mode 100644 drivers/media/rc/keymaps/rc-hauppauge.c delete mode 100644 drivers/media/rc/keymaps/rc-rc5-hauppauge-new.c [Jarod: fix up RC_MAP_HAUPPAUGE defines] Signed-off-by:
-
Mauro Carvalho Chehab authored
The keys for the old black were messed with the ones for the hauppauge grey. Fix it. Also, fixes some keycodes and order the keys according with the way they appear inside the remote controller. Signed-off-by:
-
Mauro Carvalho Chehab authored
Hans borrowed me an old Black Hauppauge RC. Thanks to that, we can fix the RC5 table for Hauppauge. Thanks-to: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by:
-
Mauro Carvalho Chehab authored
Adds the old grey remote controller to Hauppauge table. Hans borrowed me an old gray Hauppauge RC. Thanks to that, we can fix the RC5 table for Hauppauge. Thanks-to: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by:
-
Mauro Carvalho Chehab authored
One of the remotes has a picture available at: http://lirc.sourceforge.net/remotes/leadtek/Y04G0004.jpg As there's one variant with a set direction keys plus vol/chann keys, and the same table is used for both models, change it to represent all keys, avoiding the usage of weird function keys. Signed-off-by:
-
Mauro Carvalho Chehab authored
Signed-off-by:
-
Mauro Carvalho Chehab authored
This driver uses an app-specific keymap for one of the tables. This is wrong. Instead, use the standard keycodes. Signed-off-by:
-
Mauro Carvalho Chehab authored
This driver uses an app-specific keymap for one of the tables. This is wrong. Instead, use the standard keycodes. Signed-off-by:
-
Mauro Carvalho Chehab authored
Using xev and testing the "Windows" key on a normal keyboard, it is mapped as KEY_LEFTMETA. So, as this is the standard code for it, use it, instead of a generic, meaningless KEY_PROG1. Signed-off-by:
-
Mauro Carvalho Chehab authored
Those KEY_PROG[n] keys were used on places where the developer didn't know for sure what key should be used. On several cases, using KEY_RED, KEY_GREEN, KEY_YELLOW would be enough. On others, there are specific keys for that already. Signed-off-by:
-
Mauro Carvalho Chehab authored
Each keyboard map were using a different definition for the Source/Video Source key. Behold Columbus were the only one using KEY_PROPS. As we want to standardize those keys at X11 and at userspace applications, we need to use just one code for it. Signed-off-by:
-
Mauro Carvalho Chehab authored
On a few places, KEY_MHP were used for snapshots. However, KEY_CAMERA is used for it on all the other keyboards that have a snapshot/Picture button. Signed-off-by:
-
Andy Walls authored
Update the TODO.lirc_zilog based on what has been completed. Also revised the development plan for lirc_zilog to not try and split Tx/Rx for one IR transceiver unit between lirc_zilog and ir-kbd-i2c, since that would be a ref-counting nightmare. Signed-off-by:
Andy Walls <awalls@md.metrocast.net> Signed-off-by:
-
Andy Walls authored
The total sequence of messages emitted by the ir_porbe() calls for a transceiver's two i2c_clients was confusing. Clean it up a bit. Signed-off-by:
-
Andy Walls authored
Lock the i2c_client pointers and prevent i2c_client removal when lirc_zilog is perfoming a series of operations that require valid i2c_client pointers. Signed-off-by:
-
Andy Walls authored
This is a major change to add pointer reference counting for struct IR, struct IR_tx, and struct IR_rx object instances. This ref counting gets lirc_zilog closer to gracefully handling bridge drivers and hot-unplugged USB devices disappearing out from under lirc_zilog when the /dev/lircN node is still open. (mutexes to protect the i2c_client pointers in struct IR_tx and struct IR_rx still need to be added.) This reference counting also helps lirc_zilog clean up properly when the i2c_clients disappear. Signed-off-by:
-
Andy Walls authored
ir_probe() makes a number of constant assignments into the lirc_driver object after copying in a template. Make better use of the template. Signed-off-by:
-
Andy Walls authored
Always allocate a lirc_buffer object, instead of just upon setup of the Rx i2c_client. If we do not allocate a lirc_buffer object, because we are not handling the Rx i2c_client, lirc_dev will allocate its own lirc_buffer anyway and not tell us about its location. Signed-off-by:
-
Andy Walls authored
Remove the rx->buf_lock that protected the rx->buf lirc_buffer. The underlying operations on the objects within the lirc_buffer are already protected by spinlocks, or the objects are constant (e.g. chunk_size). Signed-off-by:
-
Andy Walls authored
There is no need to take the rx->buf_lock in the the poll() function as all the underling calls made on objects in the rx->buf lirc_buffer object are protected by spinlocks. Corrected a bad error return value in poll(): return POLLERR instead of -ENODEV. Added some comments to poll() for when, in the future, I forget what poll() and poll_wait() are supposed to do. [Jarod: minor debug spew fix] Signed-off-by:
-
Andy Walls authored
lirc_zilog had its own llseek stub that returned -ESPIPE. Get rid of it and use the kernel's no_llseek() and nonseekable_open() functions instead. Signed-off-by:
-
Andy Walls authored
The open count is simply used for deciding if the Rx polling thread needs to poll the IR chip for userspace. Simplify the manipulation of the open count by using an atomic_t and not requiring a lock The polling thread errantly didn't try to take the lock anyway. Signed-off-by:
-
Andy Walls authored
Signed-off-by:
-
Andy Walls authored
The set_use_inc() and set_use_dec() functions tried to lock the underlying bridge driver device instance in memory by changing the use count on the device's i2c_clients. This worked for PCI devices (ivtv, cx18, bttv). It doesn't work for hot-pluggable usb devices (pvrusb2 and hdpvr). With usb device instances, the driver may get locked into memory, but the unplugged hardware is gone. The set_use_inc() set_use_dec() functions also tried to have lirc_zilog change its own module refernce count, which is racy and not guaranteed to work. The lirc_dev module does actually perform proper module ref count manipulation on the lirc_zilog module, so there is need for lirc_zilog to attempt a buggy module get on itself anyway. lirc_zilog also errantly called these functions on itself in open() and close(), but lirc_dev did that already too. So let's just gut the bodies of the set_use_*() functions, and remove the extra calls to them from within lirc_zilog. Proper reference counting of the struct IR, IR_rx, and IR_tx objects -- to handle the case when the underlying bttv, ivtv, cx18, hdpvr, or pvrusb2 bridge driver module or device instance goes away -- will be added in subsequent patches. Signed-off-by:
-
Andy Walls authored
This reverts commit 8090232a and adds an additional check for ir->tx == NULL. The user may need us to handle an RX only unit. Apparently there are TV capture units in existence with Rx only wiring and/or RX only firmware for the on-board Zilog Z8 IR unit. Signed-off-by:
-
Jarod Wilson authored
Make the hdpvr's i2c master implementation more closely mirror that of the pvrusb2 driver. Currently makes no significant difference in IR reception behavior with ir-kbd-i2c (i.e., it still sucks). Signed-off-by:
-
Jarod Wilson authored
Signed-off-by:
-
Jarod Wilson authored
Reported-by:
Daniel Burr <dburr@topcon.com> Signed-off-by:
-
Dmitri Belimov authored
Add compatibility for composite and s-video inputs. Some TV cards hasn't it. Fix S-Video input, the s-video cable has only video signals no audio. Call the function of audio configure kill chroma in signal. only b/w video. Known bugs: - after s-video the audio for radio didn't work, TV crashed hardly - after composite TV crashed hardly too. P.S. After this patch I'll want to rework the procedure of configure video. Now it has a lot of junk and dubles. With my best regards, Dmitry. Signed-off-by:Beholder Intl. Ltd. Dmitry Belimov <d.belimov@gmail.com> Signed-off-by:
-
Juan J. Garcia de Soria authored
Remove older drivers lirc_it87 and lirc_ite8709 from the LIRC staging area, since they're now superceded by ite-cir. Signed-off-by:
Juan J. Garcia de Soria <skandalfo@gmail.com> Tested-by:
Stephan Raue <stephan@openelec.tv> Signed-off-by:
-
