linux.git/drivers/media/rc/lirc_dev.c, branch v5.19

media: lirc: report ir receiver overflow

2022-01-28T18:32:50+00:00

If the driver reports that the hardware had an overflow, report this to
userspace. It would be nice to know when this happens, and not just get
a long space.

This change has been tested with lircd, ir-ctl, and ir-keytable.

Signed-off-by: Sean Young 
Signed-off-by: Mauro Carvalho Chehab

media: rc-core: rename ir_raw_event_reset to ir_raw_event_overflow

2022-01-28T18:32:50+00:00

The driver report a reset event when the hardware reports and overflow.
There is no reason to have a generic "reset" event.

Signed-off-by: Sean Young 
Signed-off-by: Mauro Carvalho Chehab

media: lirc: simplify gap calculation

2022-01-24T00:38:32+00:00

When a driver reports a timeout, no more IR activity will be reported
until the next pulse. A space is inserted between the timeout and the
next pulse, based on ktime.

The timeout reports already a duration, so this duration should not be
added to the gap. Otherwise there is no change to the functionality.

Signed-off-by: Sean Young 
Signed-off-by: Mauro Carvalho Chehab

media: lirc: always send timeout reports

2021-12-14T14:09:12+00:00

Without timeout reports, it is impossible to decode many protocols since
it is not known when the transmission ends. timeout reports are sent by
default, but can be turned off. There is no reason to turn them off, and
I cannot find any software which does this, so we can safely remove it.

This makes the ioctl LIRC_SET_REC_TIMEOUT_REPORTS a no-op.

Signed-off-by: Sean Young 
Signed-off-by: Mauro Carvalho Chehab

media: rc: rename s_learning_mode() to s_wideband_receiver()

2021-07-22T06:21:53+00:00

The s_learning_mode() function is called in response to the ioctl
LIRC_SET_WIDEBAND_RECEIVER, so rename it to s_wideband_receiver().

Learning mode is when both the wideband receiver is turned on and
carrier reports are enabled.

Signed-off-by: Sean Young 
Signed-off-by: Mauro Carvalho Chehab

media: rc: validate that "rc_proto" is reasonable

2020-11-17T05:57:10+00:00

Smatch complains that "rc_proto" comes from the user and it can result
in shift wrapping in ir_raw_encode_scancode()

    drivers/media/rc/rc-ir-raw.c:526 ir_raw_encode_scancode()
    error: undefined (user controlled) shift '1 << protocol'

This is true, but I reviewed the surrounding code and it appears
harmless. Anyway, let's verify that "rc_proto" is valid as a kernel
hardening measure.

Signed-off-by: Dan Carpenter 
Signed-off-by: Sean Young 
Signed-off-by: Mauro Carvalho Chehab

media: rc: rename ir_lirc_* functions to lirc_*

2020-09-03T14:19:27+00:00

Remove pointless ir_ prefix.

Signed-off-by: Sean Young 
Signed-off-by: Mauro Carvalho Chehab

media: rc: harmonize infrared durations to microseconds

2020-09-03T14:18:55+00:00

rc-core kapi uses nanoseconds for infrared durations for receiving, and
microseconds for sending. The uapi already uses microseconds for both,
so this patch does not change the uapi.

Infrared durations do not need nanosecond resolution. IR protocols do not
have durations shorter than about 100 microseconds. Some IR hardware offers
250 microseconds resolution, which is sufficient for most protocols.
Better hardware has 50 microsecond resolution and is enough for every
protocol I am aware off.

Unify on microseconds everywhere. This simplifies the code since less
conversion between microseconds and nanoseconds needs to be done.

This affects:
 - rx_resolution member of struct rc_dev
 - timeout member of struct rc_dev
 - duration member in struct ir_raw_event

Cc: "Bruno Prémont" 
Cc: Hans Verkuil 
Cc: Maxim Levitsky 
Cc: Patrick Lerda 
Cc: Kevin Hilman 
Cc: Neil Armstrong 
Cc: Jerome Brunet 
Cc: Martin Blumenstingl 
Cc: Sean Wang 
Cc: Matthias Brugger 
Cc: Patrice Chotard 
Cc: Maxime Ripard 
Cc: Chen-Yu Tsai 
Cc: "David Härdeman" 
Cc: Benjamin Valentin 
Cc: Antti Palosaari 
Signed-off-by: Sean Young 
Signed-off-by: Mauro Carvalho Chehab

media: rc: rename lirc char dev region to "lirc"

2020-09-03T14:15:18+00:00

BaseRemoteCtl is not descriptive.

Signed-off-by: Sean Young 
Signed-off-by: Mauro Carvalho Chehab

media: rc: make scancodes 64 bit

2020-03-12T08:20:46+00:00

There are many protocols that encode more than 32 bit. We want 64 bit
support so that BPF IR decoders can decode more than 32 bit. None of
the existing kernel IR decoders/encoders support 64 bit, for now.

The MSC_SCAN event can only contain 32 bit scancodes, so we only generate
MSC_SCAN events if the scancode fits into 32 bits. The full 64 bit
scancode can be read from the lirc chardev.

Signed-off-by: Sean Young 
Signed-off-by: Mauro Carvalho Chehab