- 02 7月, 2011 2 次提交
-
-
由 Jarod Wilson 提交于
While 0xffdc devices have their IR protocol hard-coded into the firmware of the device, we have no known way of telling what it is if we don't have the device's config byte already in the driver. Unknown devices default to the imon native protocol, but might actually be rc6, so we should set the driver up such that the user can load the rc6 keytable from userspace and still have a working device ahead of its config byte being added to the driver. Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Jarod Wilson 提交于
Another device with the 0xffdc device id, this one with 0x7e in the config byte. Its an iMON VFD + RC6 IR, in a CoolerMaster 260 case. Reported-by: NFilip Streibl <filip@streibl.cz> Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 11 6月, 2011 2 次提交
-
-
由 Jarod Wilson 提交于
As pointed out on the lirc list by Andreas Dick, initial panel key repeat suppression wasn't working, as we had no timevals accumulated until after the first repeat. Also add a missing locking call. Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Jarod Wilson 提交于
Courtesy of information from Andreas Dick on the lirc list. Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 21 5月, 2011 2 次提交
-
-
由 Julia Lawall 提交于
ictx->touch is intialied in imon_init_intf1, to the result of calling the function that contains this code. Thus, in this code, input_free_device should be called on touch itself. A simplified version of the semantic match that finds this problem is: (http://coccinelle.lip6.fr/) // <smpl> @r exists@ local idexpression struct input_dev * x; expression ra,rr; position p1,p2; @@ x = input_allocate_device@p1(...) ... when != x = rr when != input_free_device(x,...) when != if (...) { ... input_free_device(x,...) ...} if(...) { ... when != x = ra when forall when != input_free_device(x,...) \(return <+...x...+>; \| return@p2...; \) } @script:python@ p1 << r.p1; p2 << r.p2; @@ cocci.print_main("input_allocate_device",p1) cocci.print_secs("input_free_device",p2) // </smpl> Signed-off-by: NJulia Lawall <julia@diku.dk> Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Jarod Wilson 提交于
- Eliminate a possible circular locking lockdep warning - Make sure we don't try to unregister a vfd on a device w/a vga screen - Always free imon context after devices are removed (display_close can just error out w/no context) Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 29 4月, 2011 1 次提交
-
-
由 Jarod Wilson 提交于
The imon_ir_change_protocol function gets called two different ways, one way is from rc_register_device, for initial protocol selection/setup, and the other is via a userspace-initiated protocol change request, either by direct sysfs prodding or by something like ir-keytable. In the rc_register_device case, the imon context lock is already held, but when initiated from userspace, it is not, so we must acquire it, prior to calling send_packet, which requires that the lock is held. Without this change, there's an easily reproduceable deadlock when another function calls send_packet (such as either of the display write fops) after a userspace-initiated change_protocol. With a lock-debugging-enabled kernel, I was getting this: [ 15.014153] ===================================== [ 15.015048] [ BUG: bad unlock balance detected! ] [ 15.015048] ------------------------------------- [ 15.015048] ir-keytable/773 is trying to release lock (&ictx->lock) at: [ 15.015048] [<ffffffff814c6297>] mutex_unlock+0xe/0x10 [ 15.015048] but there are no more locks to release! [ 15.015048] [ 15.015048] other info that might help us debug this: [ 15.015048] 2 locks held by ir-keytable/773: [ 15.015048] #0: (&buffer->mutex){+.+.+.}, at: [<ffffffff8119d400>] sysfs_write_file+0x3c/0x144 [ 15.015048] #1: (s_active#87){.+.+.+}, at: [<ffffffff8119d4ab>] sysfs_write_file+0xe7/0x144 [ 15.015048] [ 15.015048] stack backtrace: [ 15.015048] Pid: 773, comm: ir-keytable Not tainted 2.6.38.4-20.fc15.x86_64.debug #1 [ 15.015048] Call Trace: [ 15.015048] [<ffffffff81089715>] ? print_unlock_inbalance_bug+0xca/0xd5 [ 15.015048] [<ffffffff8108b35c>] ? lock_release_non_nested+0xc1/0x263 [ 15.015048] [<ffffffff814c6297>] ? mutex_unlock+0xe/0x10 [ 15.015048] [<ffffffff814c6297>] ? mutex_unlock+0xe/0x10 [ 15.015048] [<ffffffff8108b67b>] ? lock_release+0x17d/0x1a4 [ 15.015048] [<ffffffff814c6229>] ? __mutex_unlock_slowpath+0xc5/0x125 [ 15.015048] [<ffffffff814c6297>] ? mutex_unlock+0xe/0x10 [ 15.015048] [<ffffffffa02964b6>] ? send_packet+0x1c9/0x264 [imon] [ 15.015048] [<ffffffff8108b376>] ? lock_release_non_nested+0xdb/0x263 [ 15.015048] [<ffffffffa0296731>] ? imon_ir_change_protocol+0x126/0x15e [imon] [ 15.015048] [<ffffffffa024a334>] ? store_protocols+0x1c3/0x286 [rc_core] [ 15.015048] [<ffffffff81326e4e>] ? dev_attr_store+0x20/0x22 [ 15.015048] [<ffffffff8119d4cc>] ? sysfs_write_file+0x108/0x144 ... The original report that led to the investigation was the following: [ 1679.457305] INFO: task LCDd:8460 blocked for more than 120 seconds. [ 1679.457307] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 1679.457309] LCDd D ffff88010fcd89c8 0 8460 1 0x00000000 [ 1679.457312] ffff8800d5a03b48 0000000000000082 0000000000000000 ffff8800d5a03fd8 [ 1679.457314] 00000000012dcd30 fffffffffffffffd ffff8800d5a03fd8 ffff88010fcd86f0 [ 1679.457316] ffff8800d5a03fd8 ffff8800d5a03fd8 ffff88010fcd89d0 ffff8800d5a03fd8 [ 1679.457319] Call Trace: [ 1679.457324] [<ffffffff810ff1a5>] ? zone_statistics+0x75/0x90 [ 1679.457327] [<ffffffff810ea907>] ? get_page_from_freelist+0x3c7/0x820 [ 1679.457330] [<ffffffff813b0a49>] __mutex_lock_slowpath+0x139/0x320 [ 1679.457335] [<ffffffff813b0c41>] mutex_lock+0x11/0x30 [ 1679.457338] [<ffffffffa0d54216>] display_open+0x66/0x130 [imon] [ 1679.457345] [<ffffffffa01d06c0>] usb_open+0x180/0x310 [usbcore] [ 1679.457349] [<ffffffff81143b3b>] chrdev_open+0x1bb/0x2d0 [ 1679.457350] [<ffffffff8113d93d>] __dentry_open+0x10d/0x370 [ 1679.457352] [<ffffffff81143980>] ? chrdev_open+0x0/0x2d0 ... Bump the driver version here so its easier to tell if people have this locking fix or not, and also make locking during probe easier to follow. CC: stable@kernel.org Reported-by: NBenjamin Hodgetts <ben@xnode.org> Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 31 3月, 2011 1 次提交
-
-
由 Lucas De Marchi 提交于
Fixes generated by 'codespell' and manually reviewed. Signed-off-by: NLucas De Marchi <lucas.demarchi@profusion.mobi>
-
- 23 3月, 2011 1 次提交
-
-
由 Jarod Wilson 提交于
Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 19 1月, 2011 3 次提交
-
-
由 Jarod Wilson 提交于
My initial thinking was that we should default to mouse mode, so people could use the mouse function to click on something on a login screen, but a lot of systems where a remote is useful automatically log in a user and launch a media center application, some of which hide the mouse, which can be confusing to users if they punch buttons on the remote and don't see any feedback. Plus, first and foremost, its a remote, so lets default to being a remote, and only toggle into mouse mode when the user explicitly asks for it. As a nice side-effect, this actually simplifies some of the code a fair bit... Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Jarod Wilson 提交于
Otherwise, we have a null receive buffer, and the logic all falls down, goes boom, all ffdc devs wind up as imon IR w/VFD. Oops. Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Jarod Wilson 提交于
There's a nasty bug that slipped in when the rc device interface was altered, only affecting the older 0xffdc imon devices. We were trying to access ictx->rdev->allowed_protos before ictx->rdev had been set. There's also an issue with call ordering that meant the correct keymap wasn't getting loaded for MCE IR type 0xffdc devices. Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 29 12月, 2010 7 次提交
-
-
由 Joe Perches 提交于
Signed-off-by: NJoe Perches <joe@perches.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mauro Carvalho Chehab 提交于
for i in `find drivers/staging -type f -name *.[ch]` `find include/media -type f -name *.[ch]` `find drivers/media -type f -name *.[ch]`; do sed s,IR_TYPE,RC_TYPE,g <$i >a && mv a $i; done for i in `find drivers/staging -type f -name *.[ch]` `find include/media -type f -name *.[ch]` `find drivers/media -type f -name *.[ch]`; do sed s,ir_type,rc_type,g <$i >a && mv a $i; done Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mauro Carvalho Chehab 提交于
Those functions are not InfraRed specific. So, rename them to properly reflect it. Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mauro Carvalho Chehab 提交于
The Remote Controller subsystem is meant to be used not only by Infra Red but also for similar types of Remote Controllers. The core is not specific to Infra Red. As such, rename: - ir-core.h to rc-core.h - IR_CORE to RC_CORE - namespace inside rc-core.c/rc-core.h To be consistent with the other changes. No functional change on this patch. Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 David Härdeman 提交于
This patch merges the ir_input_dev and ir_dev_props structs into a single struct called rc_dev. The drivers and various functions in rc-core used by the drivers are also changed to use rc_dev as the primary interface when dealing with rc-core. This means that the input_dev is abstracted away from the drivers which is necessary if we ever want to support multiple input devs per rc device. The new API is similar to what the input subsystem uses, i.e: rc_device_alloc() rc_device_free() rc_device_register() rc_device_unregister() [mchehab@redhat.com: Fix compilation on mceusb and cx231xx, due to merge conflicts] Signed-off-by: NDavid Härdeman <david@hardeman.nu> Acked-by: NJarod Wilson <jarod@redhat.com> Tested-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mauro Carvalho Chehab 提交于
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 David Härdeman 提交于
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: NDavid Härdeman <david@hardeman.nu> Acked-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 24 10月, 2010 3 次提交
-
-
由 Jarod Wilson 提交于
Pointed out by Bonne Eggleston on the lirc list. Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Jarod Wilson 提交于
There was a redundant call to imon_ir_change_protocol -- its already getting called from ir_input_register. Also do some minor housekeeping with var names and formatting. Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Jarod Wilson 提交于
Somehow, I managed to screw things up when reworking the rdev/idev split patch from David, and started trying to get ir_input_dev from idev instead of rdev, thus resulting in button presses hanging the system. This fixes it. Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 23 10月, 2010 1 次提交
-
-
由 Joe Perches 提交于
Use the standard error logging mechanisms. Add #define pr_fmt(fmt) KBUILD_MODNAME ":%s" fmt, __func__ Remove __func__ from err calls, add '\n', rename to pr_err Signed-off-by: NJoe Perches <joe@perches.com> Acked-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 21 10月, 2010 3 次提交
-
-
由 Jarod Wilson 提交于
Currently, they get set up with the pad keytable, which they can't actually use at all. Also add another variant of volume scancodes from another 0xffdc device, and properly set up the 0x9e 0xffdc device as an iMON VFD w/MCE proto IR. Based on data and a prior patch from Anders Eriksson on the lirc list. Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Jarod Wilson 提交于
Lest we get our keycodes wrong... Thus far, in practice, I've not found it to actually matter, but its one of the issues raised in https://bugzilla.kernel.org/show_bug.cgi?id=16351 that wasn't addressed by converting to using native IR keydown/up functions. Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 David Härdeman 提交于
This is a stab at separating the mouse (and front panel/knob) events out to a separate input device. This is necessary in preparation for the next patch which makes the rc-core input dev opaque to rc drivers. I can't verify the correctness of the patch beyond the fact that it compiles without warnings. The driver has resisted most of my attempts at understanding it properly...for example, the double calls to le64_to_cpu() and be64_to_cpu() which are applied in imon_incoming_packet() and imon_panel_key_lookup() would amount to a bswab64() call, irregardless of the cpu endianness, and I think the code wouldn't have worked on a big-endian machine... - Minor alterations to apply with minimal core IR changes - Use timer for imon keys too, since its entirely possible for the receiver to miss release codes (either by way of another key being pressed while the first is held or by the remote pointing away from the recevier when the key is release. yes, I know, its ugly). - Bump driver version number, since this is a fairly significant change (for the much much better). Tested successfully w/an imon knob receiver. Signed-off-by: NDavid Härdeman <david@hardeman.nu> Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 15 10月, 2010 1 次提交
-
-
由 Arnd Bergmann 提交于
All file_operations should get a .llseek operation so we can make nonseekable_open the default for future file operations without a .llseek pointer. The three cases that we can automatically detect are no_llseek, seq_lseek and default_llseek. For cases where we can we can automatically prove that the file offset is always ignored, we use noop_llseek, which maintains the current behavior of not returning an error from a seek. New drivers should normally not use noop_llseek but instead use no_llseek and call nonseekable_open at open time. Existing drivers can be converted to do the same when the maintainer knows for certain that no user code relies on calling seek on the device file. The generated code is often incorrectly indented and right now contains comments that clarify for each added line why a specific variant was chosen. In the version that gets submitted upstream, the comments will be gone and I will manually fix the indentation, because there does not seem to be a way to do that using coccinelle. Some amount of new code is currently sitting in linux-next that should get the same modifications, which I will do at the end of the merge window. Many thanks to Julia Lawall for helping me learn to write a semantic patch that does all this. ===== begin semantic patch ===== // This adds an llseek= method to all file operations, // as a preparation for making no_llseek the default. // // The rules are // - use no_llseek explicitly if we do nonseekable_open // - use seq_lseek for sequential files // - use default_llseek if we know we access f_pos // - use noop_llseek if we know we don't access f_pos, // but we still want to allow users to call lseek // @ open1 exists @ identifier nested_open; @@ nested_open(...) { <+... nonseekable_open(...) ...+> } @ open exists@ identifier open_f; identifier i, f; identifier open1.nested_open; @@ int open_f(struct inode *i, struct file *f) { <+... ( nonseekable_open(...) | nested_open(...) ) ...+> } @ read disable optional_qualifier exists @ identifier read_f; identifier f, p, s, off; type ssize_t, size_t, loff_t; expression E; identifier func; @@ ssize_t read_f(struct file *f, char *p, size_t s, loff_t *off) { <+... ( *off = E | *off += E | func(..., off, ...) | E = *off ) ...+> } @ read_no_fpos disable optional_qualifier exists @ identifier read_f; identifier f, p, s, off; type ssize_t, size_t, loff_t; @@ ssize_t read_f(struct file *f, char *p, size_t s, loff_t *off) { ... when != off } @ write @ identifier write_f; identifier f, p, s, off; type ssize_t, size_t, loff_t; expression E; identifier func; @@ ssize_t write_f(struct file *f, const char *p, size_t s, loff_t *off) { <+... ( *off = E | *off += E | func(..., off, ...) | E = *off ) ...+> } @ write_no_fpos @ identifier write_f; identifier f, p, s, off; type ssize_t, size_t, loff_t; @@ ssize_t write_f(struct file *f, const char *p, size_t s, loff_t *off) { ... when != off } @ fops0 @ identifier fops; @@ struct file_operations fops = { ... }; @ has_llseek depends on fops0 @ identifier fops0.fops; identifier llseek_f; @@ struct file_operations fops = { ... .llseek = llseek_f, ... }; @ has_read depends on fops0 @ identifier fops0.fops; identifier read_f; @@ struct file_operations fops = { ... .read = read_f, ... }; @ has_write depends on fops0 @ identifier fops0.fops; identifier write_f; @@ struct file_operations fops = { ... .write = write_f, ... }; @ has_open depends on fops0 @ identifier fops0.fops; identifier open_f; @@ struct file_operations fops = { ... .open = open_f, ... }; // use no_llseek if we call nonseekable_open //////////////////////////////////////////// @ nonseekable1 depends on !has_llseek && has_open @ identifier fops0.fops; identifier nso ~= "nonseekable_open"; @@ struct file_operations fops = { ... .open = nso, ... +.llseek = no_llseek, /* nonseekable */ }; @ nonseekable2 depends on !has_llseek @ identifier fops0.fops; identifier open.open_f; @@ struct file_operations fops = { ... .open = open_f, ... +.llseek = no_llseek, /* open uses nonseekable */ }; // use seq_lseek for sequential files ///////////////////////////////////// @ seq depends on !has_llseek @ identifier fops0.fops; identifier sr ~= "seq_read"; @@ struct file_operations fops = { ... .read = sr, ... +.llseek = seq_lseek, /* we have seq_read */ }; // use default_llseek if there is a readdir /////////////////////////////////////////// @ fops1 depends on !has_llseek && !nonseekable1 && !nonseekable2 && !seq @ identifier fops0.fops; identifier readdir_e; @@ // any other fop is used that changes pos struct file_operations fops = { ... .readdir = readdir_e, ... +.llseek = default_llseek, /* readdir is present */ }; // use default_llseek if at least one of read/write touches f_pos ///////////////////////////////////////////////////////////////// @ fops2 depends on !fops1 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @ identifier fops0.fops; identifier read.read_f; @@ // read fops use offset struct file_operations fops = { ... .read = read_f, ... +.llseek = default_llseek, /* read accesses f_pos */ }; @ fops3 depends on !fops1 && !fops2 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @ identifier fops0.fops; identifier write.write_f; @@ // write fops use offset struct file_operations fops = { ... .write = write_f, ... + .llseek = default_llseek, /* write accesses f_pos */ }; // Use noop_llseek if neither read nor write accesses f_pos /////////////////////////////////////////////////////////// @ fops4 depends on !fops1 && !fops2 && !fops3 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @ identifier fops0.fops; identifier read_no_fpos.read_f; identifier write_no_fpos.write_f; @@ // write fops use offset struct file_operations fops = { ... .write = write_f, .read = read_f, ... +.llseek = noop_llseek, /* read and write both use no f_pos */ }; @ depends on has_write && !has_read && !fops1 && !fops2 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @ identifier fops0.fops; identifier write_no_fpos.write_f; @@ struct file_operations fops = { ... .write = write_f, ... +.llseek = noop_llseek, /* write uses no f_pos */ }; @ depends on has_read && !has_write && !fops1 && !fops2 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @ identifier fops0.fops; identifier read_no_fpos.read_f; @@ struct file_operations fops = { ... .read = read_f, ... +.llseek = noop_llseek, /* read uses no f_pos */ }; @ depends on !has_read && !has_write && !fops1 && !fops2 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @ identifier fops0.fops; @@ struct file_operations fops = { ... +.llseek = noop_llseek, /* no read or write fn */ }; ===== End semantic patch ===== Signed-off-by: NArnd Bergmann <arnd@arndb.de> Cc: Julia Lawall <julia@diku.dk> Cc: Christoph Hellwig <hch@infradead.org>
-
- 09 8月, 2010 2 次提交
-
-
由 Jarod Wilson 提交于
The ir_input_dev gets filled in by __ir_input_register, the one allocated in imon_init_idev was being overwritten by the correct one shortly after it was initialized (ultimately resulting in a memory leak). Additionally, there was an ill-advised memcpy into that extraneous ir_input_dev which gets fixed by this. Ill-advised memcpy pointed out by Dmitry Torokhov, bad usage of ir_input_dev pointed out by Maxim Levitsky. Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Jarod Wilson 提交于
Per Dmitry Torokhov, following input_unregister_device with an input_free_device is forbidden, the former is sufficient alone. Acked-by: NDmitry Torokhov <dtor@mail.ru> Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 03 8月, 2010 3 次提交
-
-
由 Joe Perches 提交于
Signed-off-by: NJoe Perches <joe@perches.com> Acked-by: NJarod Wilson <jarod@redhat.com> Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Jarod Wilson 提交于
Per Pieter Hoekstra: I have a Antec Fusion with a iMON Lcd and I get the following error: imon 6-1:1.0: Unknown 0xffdc device, defaulting to VFD and iMON IR (id 0x9e) The driver is functional if I load it like this: (I do not use a remote for it) modprobe imon display_type=1 (On Mythbuntu 10.04/2.6.32) This device is a lcd-type with support for a MCE remote. Looking at the source code, this device (0x9e) is the same as id 0x9f. Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Jarod Wilson 提交于
Was using input_unregister_device directly, instead of using ir_input_unregister, which tears down a bunch of other things in addition to eventually calling input_unregister_device. Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 01 6月, 2010 2 次提交
-
-
由 Jarod Wilson 提交于
Add auto-config support for iMON 2.4G LT RF device, based on debug output from Giulio Amodeo in Red Hat bugzilla #572288. Also flips the switch on only setting up the rf associate sysfs attr only if we think we're looking at an RF device, vs. previously, setting up the attr for all 0xffdc devices, so its possible (but a bit unlikely) there's another iMON RF device we'll have to fix up. Nb: should be applied after "IR/imon: clean up usage of bools", or there will be a slight contextual mismatch. Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Jarod Wilson 提交于
There was a mix of 0/1 and false/true. Pick one convention and stick with it (I picked false/true). Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 19 5月, 2010 6 次提交
-
-
由 Jarod Wilson 提交于
On Tue, May 04, 2010 at 06:06:41PM +0200, Dan Carpenter wrote: > On Tue, May 04, 2010 at 10:03:18AM -0400, Jarod Wilson wrote: > > @@ -1205,7 +1204,7 @@ static u32 imon_panel_key_lookup(u64 hw_code) > > if (imon_panel_key_table[i].hw_code == (code | 0xffee)) > > break; > > > > - keycode = imon_panel_key_table[i % IMON_KEY_RELEASE_OFFSET].keycode; > > + keycode = imon_panel_key_table[i].keycode; > > > > return keycode; > > } > > There is still potentially a problem here because if we don't hit the > break statement, then we're one past the end of the array. D'oh. Okay, here's v2, should fix that buglet too. This hack was used when the imon driver was using internal key lookup routines, but became dead weight when the driver was converted to use ir-core's key lookup routines. These bits simply didn't get removed, drop 'em now. Pointed out by Dan Carpenter. v2: fix possible attempt to access beyond end of key table array, also pointed out by Dan. Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Dan Carpenter 提交于
If there is an error here we should unlock in the caller (which is imon_init_intf1()). We can remove this stray unlock. Signed-off-by: NDan Carpenter <error27@gmail.com> Acked-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Dan Carpenter 提交于
There is a typo here. We meant to test "ir" instead of "props". The "props" variable was tested earlier. Signed-off-by: NDan Carpenter <error27@gmail.com> Acked-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Dan Carpenter 提交于
The original condition is always false because ! has higher precedence than == and neither 0 nor 1 is equal to IMON_DISPLAY_TYPE_VGA. Signed-off-by: NDan Carpenter <error27@gmail.com> Acked-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Jarod Wilson 提交于
Simplified from version 1, in that hacks heisted from ati_remote2.c aren't actually necessary, the real fix for too many repeats was from setting too long a timer release value (200ms) on repeats in mce mode -- this patch drops the release timeout to 33ms, matching the input subsystem default input_dev->rep[REP_PERIOD]. Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Jarod Wilson 提交于
This is a follow-up to my prior patch implementing ir-core's change_protocol functionality in the imon driver, which eliminates a false warning when change_protocol is called without a specific protocol selected yet (i.e., still IR_TYPE_UNKNOWN). It also removes some extraneous blank lines getting spewn into dmesg. Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-