| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
It works on hardware other than Macbook Pros, and it works on GPUs other
than Nvidia. It should even work on iMacs, so change the name to match
reality more precisely and include an alias so existing users don't get
confused.
Signed-off-by: Matthew Garrett <[email protected]>
Acked-by: Richard Purdie <[email protected]>
Cc: Mourad De Clerck <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
The SMI-based backlight control functionality may fail to work if the
system is running under EFI rather than BIOS. Check that the hardware
responds as expected, and exit if it doesn't.
Signed-off-by: Matthew Garrett <[email protected]>
Acked-by: Richard Purdie <[email protected]>
Cc: Mourad De Clerck <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
This driver only has to deal with two different classes of hardware, but
right now it needs new DMI entries for every new machine. It turns out
that there's an ACPI device that uniquely identifies Apples with backlights,
so this patch reworks the driver into an ACPI one, identifies the hardware
by checking the PCI vendor of the root bridge and strips out all the DMI
code. It also changes the config text to clarify that it works on devices
other than Macbook Pros and GPUs other than nvidia.
Signed-off-by: Matthew Garrett <[email protected]>
Acked-by: Richard Purdie <[email protected]>
Cc: Mourad De Clerck <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Dual-GPU machines may provide more than one ACPI backlight interface. Tie
the backlight device to the GPU in order to allow userspace to identify
the correct interface.
Signed-off-by: Matthew Garrett <[email protected]>
Cc: Richard Purdie <[email protected]>
Cc: Chris Wilson <[email protected]>
Cc: David Airlie <[email protected]>
Cc: Alex Deucher <[email protected]>
Cc: Ben Skeggs <[email protected]>
Cc: Zhang Rui <[email protected]>
Cc: Len Brown <[email protected]>
Cc: Jesse Barnes <[email protected]>
Tested-by: Sedat Dilek <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
We may eventually end up with per-connector backlights, especially with
ddcci devices. Make sure that the parent node for the backlight device is
the connector rather than the PCI device.
Signed-off-by: Matthew Garrett <[email protected]>
Cc: Richard Purdie <[email protected]>
Cc: Chris Wilson <[email protected]>
Cc: David Airlie <[email protected]>
Cc: Alex Deucher <[email protected]>
Acked-by: Ben Skeggs <[email protected]>
Cc: Zhang Rui <[email protected]>
Cc: Len Brown <[email protected]>
Cc: Jesse Barnes <[email protected]>
Tested-by: Sedat Dilek <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Allows e.g. power management daemons to control the backlight level. Inspired
by the corresponding code in radeonfb.
[[email protected]: updated to add backlight type and make the connector the parent device]
Signed-off-by: Michel Dänzer <[email protected]>
Signed-off-by: Matthew Garrett <[email protected]>
Cc: Richard Purdie <[email protected]>
Cc: Chris Wilson <[email protected]>
Cc: David Airlie <[email protected]>
Acked-by: Alex Deucher <[email protected]>
Cc: Ben Skeggs <[email protected]>
Cc: Zhang Rui <[email protected]>
Cc: Len Brown <[email protected]>
Cc: Jesse Barnes <[email protected]>
Tested-by: Sedat Dilek <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
There may be multiple ways of controlling the backlight on a given
machine. Allow drivers to expose the type of interface they are
providing, making it possible for userspace to make appropriate policy
decisions.
Signed-off-by: Matthew Garrett <[email protected]>
Cc: Richard Purdie <[email protected]>
Cc: Chris Wilson <[email protected]>
Cc: David Airlie <[email protected]>
Cc: Alex Deucher <[email protected]>
Cc: Ben Skeggs <[email protected]>
Cc: Zhang Rui <[email protected]>
Cc: Len Brown <[email protected]>
Cc: Jesse Barnes <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Don't allow everybody to change LED settings.
Signed-off-by: Vasiliy Kulikov <[email protected]>
Cc: Richard Purdie <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Don't allow everybody to change LED settings.
Signed-off-by: Vasiliy Kulikov <[email protected]>
Cc: Richard Purdie <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Add a ld9040 amoled panel driver.
Signed-off-by: Donghwa Lee <[email protected]>
Signed-off-by: Kyungmin Park <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
Cc: Richard Purdie <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
And fix a typo.
Signed-off-by: Uwe Kleine-König <[email protected]>
Cc: Lars-Peter Clausen <[email protected]>
Cc: Richard Purdie <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Simple backlight driver for National Semiconductor LM3530. Presently only
manual mode is supported, PWM and ALS support to be added.
Signed-off-by: Shreshtha Kumar Sahu <[email protected]>
Cc: Linus Walleij <[email protected]>
Cc: Richard Purdie <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
There is a move to deprecate bus-specific PM operations and move to using
dev_pm_ops instead in order to reduce the amount of boilerplate code in
buses and facilitiate updates to the PM core. Do this move for the bs2802
driver.
[[email protected]: fix warnings]
Signed-off-by: Mark Brown <[email protected]>
Cc: Kim Kyuwon <[email protected]>
Cc: Kim Kyuwon <[email protected]>
Cc: Richard Purdie <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
list_del() leaves poison in the prev and next pointers. The next
list_empty() will compare those poisons, and say the list isn't empty.
Any list operations that assume the node is on a list because of such a
check will be fooled into dereferencing poison. One needs to INIT the
node after the del, and fortunately there's already a wrapper for that -
list_del_init().
Some of the dels are followed by deallocations, so can be ignored, and one
can be merged with an add to make a move. Apart from that, I erred on the
side of caution in making nodes list_empty()-queriable.
Signed-off-by: Phil Carmody <[email protected]>
Reviewed-by: Paul Menage <[email protected]>
Cc: Li Zefan <[email protected]>
Acked-by: Kirill A. Shutemov <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
The oom killer naturally defers killing anything if it finds an eligible
task that is already exiting and has yet to detach its ->mm. This avoids
unnecessarily killing tasks when one is already in the exit path and may
free enough memory that the oom killer is no longer needed. This is
detected by PF_EXITING since threads that have already detached its ->mm
are no longer considered at all.
The problem with always deferring when a thread is PF_EXITING, however, is
that it may never actually exit when being traced, specifically if another
task is tracing it with PTRACE_O_TRACEEXIT. The oom killer does not want
to defer in this case since there is no guarantee that thread will ever
exit without intervention.
This patch will now only defer the oom killer when a thread is PF_EXITING
and no ptracer has stopped its progress in the exit path. It also ensures
that a child is sacrificed for the chosen parent only if it has a
different ->mm as the comment implies: this ensures that the thread group
leader is always targeted appropriately.
Signed-off-by: David Rientjes <[email protected]>
Reported-by: Oleg Nesterov <[email protected]>
Cc: KOSAKI Motohiro <[email protected]>
Cc: KAMEZAWA Hiroyuki <[email protected]>
Cc: Hugh Dickins <[email protected]>
Cc: Andrey Vagin <[email protected]>
Cc: <[email protected]> [2.6.38.x]
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
We shouldn't defer oom killing if a thread has already detached its ->mm
and still has TIF_MEMDIE set. Memory needs to be freed, so find kill
other threads that pin the same ->mm or find another task to kill.
Signed-off-by: Andrey Vagin <[email protected]>
Signed-off-by: David Rientjes <[email protected]>
Cc: KOSAKI Motohiro <[email protected]>
Cc: <[email protected]> [2.6.38.x]
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
This patch prevents unnecessary oom kills or kernel panics by reverting
two commits:
495789a5 (oom: make oom_score to per-process value)
cef1d352 (oom: multi threaded process coredump don't make deadlock)
First, 495789a5 (oom: make oom_score to per-process value) ignores the
fact that all threads in a thread group do not necessarily exit at the
same time.
It is imperative that select_bad_process() detect threads that are in the
exit path, specifically those with PF_EXITING set, to prevent needlessly
killing additional tasks. If a process is oom killed and the thread group
leader exits, select_bad_process() cannot detect the other threads that
are PF_EXITING by iterating over only processes. Thus, it currently
chooses another task unnecessarily for oom kill or panics the machine when
nothing else is eligible.
By iterating over threads instead, it is possible to detect threads that
are exiting and nominate them for oom kill so they get access to memory
reserves.
Second, cef1d352 (oom: multi threaded process coredump don't make
deadlock) erroneously avoids making the oom killer a no-op when an
eligible thread other than current isfound to be exiting. We want to
detect this situation so that we may allow that exiting thread time to
exit and free its memory; if it is able to exit on its own, that should
free memory so current is no loner oom. If it is not able to exit on its
own, the oom killer will nominate it for oom kill which, in this case,
only means it will get access to memory reserves.
Without this change, it is easy for the oom killer to unnecessarily target
tasks when all threads of a victim don't exit before the thread group
leader or, in the worst case, panic the machine.
Signed-off-by: David Rientjes <[email protected]>
Cc: KOSAKI Motohiro <[email protected]>
Cc: KAMEZAWA Hiroyuki <[email protected]>
Cc: Oleg Nesterov <[email protected]>
Cc: Hugh Dickins <[email protected]>
Cc: Andrey Vagin <[email protected]>
Cc: <[email protected]> [2.6.38.x]
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
If an administrator tries to swapon a file backed by NFS, the inode mutex is
taken (as it is for any swapfile) but later identified to be a bad swapfile
due to the lack of bmap and tries to cleanup. During cleanup, an attempt is
made to close the file but with inode->i_mutex still held. Closing an NFS
file syncs it which tries to acquire the inode mutex leading to deadlock. If
lockdep is enabled the following appears on the console;
=============================================
[ INFO: possible recursive locking detected ]
2.6.38-rc8-autobuild #1
---------------------------------------------
swapon/2192 is trying to acquire lock:
(&sb->s_type->i_mutex_key#13){+.+.+.}, at: vfs_fsync_range+0x47/0x7c
but task is already holding lock:
(&sb->s_type->i_mutex_key#13){+.+.+.}, at: sys_swapon+0x28d/0xae7
other info that might help us debug this:
1 lock held by swapon/2192:
#0: (&sb->s_type->i_mutex_key#13){+.+.+.}, at: sys_swapon+0x28d/0xae7
stack backtrace:
Pid: 2192, comm: swapon Not tainted 2.6.38-rc8-autobuild #1
Call Trace:
__lock_acquire+0x2eb/0x1623
find_get_pages_tag+0x14a/0x174
pagevec_lookup_tag+0x25/0x2e
vfs_fsync_range+0x47/0x7c
lock_acquire+0xd3/0x100
vfs_fsync_range+0x47/0x7c
nfs_flush_one+0x0/0xdf [nfs]
mutex_lock_nested+0x40/0x2b1
vfs_fsync_range+0x47/0x7c
vfs_fsync_range+0x47/0x7c
vfs_fsync+0x1c/0x1e
nfs_file_flush+0x64/0x69 [nfs]
filp_close+0x43/0x72
sys_swapon+0xa39/0xae7
sysret_check+0x2e/0x69
system_call_fastpath+0x16/0x1b
This patch releases the mutex if its held before calling filep_close()
so swapon fails as expected without deadlock when the swapfile is backed
by NFS. If accepted for 2.6.39, it should also be considered a -stable
candidate for 2.6.38 and 2.6.37.
Signed-off-by: Mel Gorman <[email protected]>
Acked-by: Hugh Dickins <[email protected]>
Cc: <[email protected]> [2.6.37+]
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
syncfs() is duplicating name_to_handle_at() due to a merging mistake.
Cc: Sage Weil <[email protected]>
Cc: Al Viro <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Remove pointless memset() in nfsacl_encode().
Thanks to Trond Myklebust <[email protected]> for pointing out
that it is not needed since posix_acl_init() will set everything
regardless..
Signed-off-by: Jesper Juhl <[email protected]>
Signed-off-by: Trond Myklebust <[email protected]>
|
|
d_alloc_and_lookup() calls i_op->lookup method due to
rootfh changes his fsid.
During mount i_op of NFS root inode is set to
nfs_mountpoint_inode_operations, if rpc_ops->getroot()
and rpc_ops->getattr() return different fsid.
After that nfs_follow_remote_path() raised oops:
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [< (null)>] (null)
stack trace:
d_alloc_and_lookup+0x4c/0x74
do_lookup+0x1e3/0x280
link_path_walk+0x12e/0xab0
nfs4_remote_get_sb+0x56/0x2c0 [nfs]
path_walk+0x67/0xe0
vfs_path_lookup+0x8e/0x100
nfs_follow_remote_path+0x16f/0x3e0 [nfs]
nfs4_try_mount+0x6f/0xd0 [nfs]
nfs_get_sb+0x269/0x400 [nfs]
vfs_kern_mount+0x8a/0x1f0
do_kern_mount+0x52/0x130
do_mount+0x20a/0x260
sys_mount+0x90/0xe0
system_call_fastpath+0x16/0x1b
So just refresh fsid, as RFC3530 doesn't specify behavior
in case of rootfh changes fsid.
Signed-off-by: Vitaliy Gusev <[email protected]>
Signed-off-by: Trond Myklebust <[email protected]>
|
|
It's been a few kernel versions now without any unexpected surprises, so
tentatively bump up the support status.
Signed-off-by: Paul Mundt <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6
* 'slab/urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6:
slub: Add statistics for this_cmpxchg_double failures
slub: Add missing irq restore for the OOM path
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/ericvh/v9fs
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ericvh/v9fs:
[net/9p]: Introduce basic flow-control for VirtIO transport.
9p: use the updated offset given by generic_write_checks
[net/9p] Don't re-pin pages on retrying virtqueue_add_buf().
[net/9p] Set the condition just before waking up.
[net/9p] unconditional wake_up to proc waiting for space on VirtIO ring
fs/9p: Add v9fs_dentry2v9ses
fs/9p: Attach writeback_fid on first open with WR flag
fs/9p: Open writeback fid in O_SYNC mode
fs/9p: Use truncate_setsize instead of vmtruncate
net/9p: Fix compile warning
net/9p: Convert the in the 9p rpc call path to GFP_NOFS
fs/9p: Fix race in initializing writeback fid
|
|
* git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client:
rbd: use watch/notify for changes in rbd header
libceph: add lingering request and watch/notify event framework
rbd: update email address in Documentation
ceph: rename dentry_release -> d_release, fix comment
ceph: add request to the tail of unsafe write list
ceph: remove request from unsafe list if it is canceled/timed out
ceph: move readahead default to fs/ceph from libceph
ceph: add ino32 mount option
ceph: update common header files
ceph: remove debugfs debug cruft
libceph: fix osd request queuing on osdmap updates
ceph: preserve I_COMPLETE across rename
libceph: Fix base64-decoding when input ends in newline.
|
|
Now that Documentation/devicetree/bindings/fb/ exists, make sure it's
also matched by the default framebuffer entry.
Signed-off-by: Paul Mundt <[email protected]>
|
|
Using delayed-work for tty flip buffers ends up causing us to wait for
the next tick to complete some actions. That's usually not all that
noticeable, but for certain latency-critical workloads it ends up being
totally unacceptable.
As an extreme case of this, passing a token back-and-forth over a pty
will take two ticks per iteration, so even just a thousand iterations
will take 8 seconds assuming a common 250Hz configuration.
Avoiding the whole delayed work issue brings that ping-pong test-case
down to 0.009s on my machine.
In more practical terms, this latency has been a performance problem for
things like dive computer simulators (simulating the serial interface
using the ptys) and for other environments (Alan mentions a CP/M emulator).
Reported-by: Jef Driesen <[email protected]>
Acked-by: Greg KH <[email protected]>
Acked-by: Alan Cox <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Now that there is a Documentation/devicetree hierarchy, and the driver in
question has no specific platform dependency, move the binding
information to a more appropriate place.
Signed-off-by: Paul Mundt <[email protected]>
|
|
pstore_dump() can be called with many different "reason" codes. Save
the name of the code in the persistent store record.
Also - only worthwhile calling pstore_mkfile for KMSG_DUMP_OOPS - that
is the only one where the kernel will continue running.
Reviewed-by: Seiji Aguchi <[email protected]>
Signed-off-by: Tony Luck <[email protected]>
|
|
Bugzilla bug 31422 reports occasional "page allocation failure. order:4"
at Squashfs mount time. Fix this by making zlib workspace allocation
use vmalloc rather than kmalloc.
Reported-by: Mehmet Giritli <[email protected]>
Signed-off-by: Phillip Lougher <[email protected]>
|
|
If we call xs_close(), we're in one of two situations:
- Autoclose, which means we don't expect to resend a request
- bind+connect failed, which probably means the port is in use
Signed-off-by: Trond Myklebust <[email protected]>
Cc: [email protected]
|
|
dma_addr_t may not fit into void* on some architectures. To be safe, make
vb2_dma_contig_cookie() return a pointer to dma_addr_t and dereference it
in vb2_dma_contig_plane_paddr() back to dma_addr_t.
Signed-off-by: Pawel Osciak <[email protected]>
Reported-by: Hans Verkuil <[email protected]>
Signed-off-by: Guennadi Liakhovetski <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
|
|
Use vb2_dma_contig_plane_paddr to retrieve a physical address for a plane
instead of calling an internal mem_ops callback.
Signed-off-by: Pawel Osciak <[email protected]>
Signed-off-by: Guennadi Liakhovetski <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Guennadi Liakhovetski <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
|
|
Commit 4aa5f366431fe (avr32: at32ap700x: specify DMA src and dst
masters) specified the masters for the ac97c playback device
but incorrectly set them in the capture slave information rather
than playback.
Cc: Hans-Christian Egtvedt <[email protected]>
Reported-by: Nicolas Ferre <[email protected]>
Signed-off-by: Jamie Iles <[email protected]>
Acked-by: Vinod Koul <[email protected]>
[rebased on dmaengine for 2.6.39 (d42efe6b)]
Signed-off-by: Dan Williams <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
|
|
Signed-off-by: Jarod Wilson <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
|
|
Give it a few tries, then exit. Prevents a possible endless loop
situation.
Signed-off-by: Jarod Wilson <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
|
|
Both lirc_imon and lirc_sasem were causing gcc to complain about the
possible use of uninitialized variables.
Signed-off-by: Jarod Wilson <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
|
|
The new hauppauge key tables use both device code button code.
Signed-off-by: Jarod Wilson <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Jarod Wilson <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Jarod Wilson <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Jarod Wilson <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Jarod Wilson <[email protected]>
|
|
Hans borrowed me an old Black Hauppauge RC. Thanks to that, we
can fix the RC5 table for Hauppauge.
Thanks-to: Hans Verkuil <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Jarod Wilson <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Jarod Wilson <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Jarod Wilson <[email protected]>
|
|
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Jarod Wilson <[email protected]>
|