something like
rc5_signal_change(ptr, space_or_mark, microseconds).
At least mark-space or space-mark events must be reported. For better
reliability, both of them.
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord
Jon Smirl jonsm...@gmail.com writes:
Data could be sent to the in-kernel decoders first and then if they
don't handle it, send it to user space.
Nope. It should be sent to all of them, they aren't dependent.
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line unsubscribe linux
obviously need simultaneous operation of in-kernel decoders.
--
Krzysztof Halasa
--
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
optimization, the protocol could stay enabled all the
time, only wasting the cycles.
--
Krzysztof Halasa
--
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
.
--
Krzysztof Halasa
--
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
on protocols where you just have those fields.
Precisely.
--
Krzysztof Halasa
--
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
must have at least one common decoder merged with the core code,
otherwise you don't know if the core is adequate. And you have to have
at least one common input device.
But perhaps it is a workable idea after all, given the another
decoder.
--
Krzysztof Halasa
--
To unsubscribe from this list: send
Mauro Carvalho Chehab mche...@redhat.com writes:
The enable/disable protocol decoder enable/disable interface is needed anyway,
due to the needs for the hardware IR decoders
Why do they need it exactly?
The key tables say all they need I hope?
--
Krzysztof Halasa
--
To unsubscribe from
, why complicate it?
There is no need for the kernel thread if the handler is fast (and it
is).
Userspace is obviously different.
--
Krzysztof Halasa
--
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
-in,
perhaps something similar to the embedded initrd.
--
Krzysztof Halasa
--
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
.
That means all the work has to be kept and then merged atomically,
it seems there is a lack of manpower for this.
--
Krzysztof Halasa
--
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
not
a kernel issue.
The default bundled, or PnP, won't work well in comparison to a GUI
utility, I wouldn't worry about it too much (though adding it to udev
and co is trivial and we should do it - even if not PnP but asking first
about the actual remote used).
--
Krzysztof Halasa
--
To unsubscribe
should support such things in the
kernel.
Once again: how about agreement about the LIRC interface
(kernel-userspace) and merging the actual LIRC code first? In-kernel
decoding can wait a bit, it doesn't change any kernel-user interface.
--
Krzysztof Halasa
--
To unsubscribe from this list: send
could eventually change
reserved into something useful.
But I think, if we are going to redesign it, we better use scancodes of
arbitrary length (e.g. protocol-dependent length). It should be opaque
except for the protocol handler.
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line
Jon Smirl jonsm...@gmail.com writes:
The in-kernel support can start small and add protocols and maps over
time.
Protocols, yes. Maps - we certainly don't want megatons of maps in the
kernel. The existing ones have to be removed, some time.
--
Krzysztof Halasa
--
To unsubscribe from this list
, making a correct IR core design without the LIRC merged can be
only harder.
--
Krzysztof Halasa
--
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
interface
(while not removing the input layer mode).
--
Krzysztof Halasa
--
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
is a prerequisite for a number of changes.
--
Krzysztof Halasa
--
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
codes are part of the same or different
command set.
Sharing the protocol and e.g. group code doesn't mean it's the same
remote.
Different protocol doesn't mean it's a different remote and what's more
important, doesn't mean the user wants it to be a different logical
remote.
--
Krzysztof Halasa
need to be polling the
IR serial port at a high rate, as you'll get directly the code. So, you'll
free the CPU to do something else.
Which device requires polling the port?
Most are IRQ-driven, aren't they?
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line unsubscribe linux-media
),
they are at the same level. I'd say that the same applies to PC's that
the user has dedicated to work as an MCE.
A remote can just _be_ keyboard and/or (sort of) mouse.
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord
want to continue supporting keyboard-less
machines?
--
Krzysztof Halasa
--
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
kevin granade kevin.gran...@gmail.com writes:
This idea of the in-kernel decoding being disabled when the raw API is
opened worries me.
I don't think we need to disable the in-kernel decoding automatically.
That would be rather unfortunate.
--
Krzysztof Halasa
--
To unsubscribe from this list
?
Doing so doesn't block improving input layer IR interface, does it?
--
Krzysztof Halasa
--
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
Maxim Levitsky maximlevit...@gmail.com writes:
And that's good. Especially for a popular and simple protocol such as
RC5.
Actually, it's not about adding the decoder. It's about fixing it.
I can fix it.
This is nonsense.
You forgot to say why do you think so.
--
Krzysztof Halasa
.
They are not.
Is it a problem for you?
How is your keyboard supposed to use scanner driver?
--
Krzysztof Halasa
--
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
protocol define
for RC-5_14, which will become very ugly with many non-standard protocol
variations.
No, the 14-bit version is designed to be backward compatible.
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord
) for configuration
I think we can do this gradually:
1. Merging the lirc drivers. The only stable thing needed is lirc
interface.
2. Changing IR input layer interface (media drivers and adding to lirc
drivers).
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line unsubscribe linux-media
for it to be stable.
--
Krzysztof Halasa
--
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
on platform and
endianess.
But not this: you can use fixed-width u16, u32, u64 and e.g. u8[x].
I don't know an arch which changes int sizes depending on endianness,
is there any?
32/64 binary compatibility needs some minimal effort.
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line
the EVIOCSKEYCODE
against it. Some type of create subdevice IOCTL will need to be
built.
Thinking about it, I'm not sure. Why do we want multiple remote devices?
(not multiple remotes, that's clear).
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line unsubscribe linux-media
.
Ioctls are not affected by this, since both ends are the same.
Obviously you can be affected if you try to access data as integers in
one point and as arrays of bytes in the other, but it has nothing to do
with ioctls.
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line unsubscribe
(such as
RC-based = resistor + capacitor).
--
Krzysztof Halasa
--
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
,
with are acceptable for key input.
--
Krzysztof Halasa
--
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
to be
moved to userspace as well.
--
Krzysztof Halasa
--
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
.
--
Krzysztof Halasa
--
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
Maxim Levitsky maximlevit...@gmail.com writes:
But devices that send raw pulse/space data should be handled in lirc
that will feed the data back to the kernel via uinput.
I still do want the in-kernel RCx decoding. And lirc pulse/space.
--
Krzysztof Halasa
--
To unsubscribe from this list
Dmitry Torokhov dmitry.torok...@gmail.com writes:
Why would sysfs write be slower than ioctl?
Sysfs is generally one-value, one-file. open, read/write, close.
ioctl() OTOH does everything (e.g. a whole key table) in one syscall.
--
Krzysztof Halasa
--
To unsubscribe from this list: send
Dmitry Torokhov dmitry.torok...@gmail.com writes:
One remote per
device only.
Why would you want more? One physical device usually corresponds to a
logical device. If you have 2 remotes create 2 devices.
I meant per receiver device.
--
Krzysztof Halasa
--
To unsubscribe from this list
.
But I think it's a minor implementation decision and we don't need to
look at it at this time.
--
Krzysztof Halasa
--
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
?
--
Krzysztof Halasa
--
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
.
--
Krzysztof Halasa
--
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
must also not get confused by
random signals destined for somewhere else.
This is usually not a problem. My experience is the decoding is very
reliable.
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
the
technical POV handling the protocol in the kernel is more efficient
or (/and) simpler.
--
Krzysztof Halasa
--
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
* into the kernel in the first place
is a huge step in that direction.
What I see as potentially problematic is breaking compatibility multiple
times.
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo
they will still have to parse protocols,
so will have code duplication, and will still need lirc thus.
This is not a problem. BTW I have nothing against lirc. It can get
keystrokes from input layer. That's the way I use it in fact.
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line
is avoided.
IOW, it would be worse, wouldn't it?
--
Krzysztof Halasa
--
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
for in-tree media drivers where applicable).
[*] assuming, of course, that it was actually agreed upon that
in-kernel decoding was the right way, the only way, all others will be
shot on sight. ;)
I think: in-kernel decoding only as the general, primary means. Not the
only one.
--
Krzysztof Halasa
drivers with
currently-in-kernel-but-badly-broken decoding can't be converted to
use the lirc interface if its merged into the kernel?
For many of them lirc mode can be easily _added_.
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body
), and lircd can grab events from
input layer if needed.
--
Krzysztof Halasa
--
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
config file
for the bundled remote of a given receiver would seem simple enough to
implement.
A model name maybe. Though there is this mapping thing which I think
need ioctl().
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message
Sean Young s...@mess.org writes:
Absolutely. There are a number of use cases when you want access to the
space-pulse (i.e. IR) information.
I think nobody proposes otherwise (except for devices which can't pass
this info).
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line
by userspace program.
This should also work with multiple remotes.
Then the existing drivers (such as saa713x with GPIO+IRQ-driven IR
receiver (IR signal on/off generating IRQ)) should be converted.
I think we shouldn't at this time worry about IR transmitters.
--
Krzysztof Halasa
--
To unsubscribe from
.
--
Krzysztof Halasa
--
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
should be done in a simple library
instead of requiring the daemon.
--
Krzysztof Halasa
--
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
a remote.
This can be solved by adding a few ioctls to enumerate the supported
protocols and to select the one(s) that will be handled by the kernel
driver.
The driver may have to handle many protocols simultaneously. This is not
a problem from a technical POV.
--
Krzysztof Halasa
RC5 but what
if I couldn't set the protocol?). Sure, it requires a bit of hackery
(not with pulse code and lircd).
I think this will just make the driver more complex without need.
Not much more, and there is a need.
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line
. Most people's set
top boxes and/or televisions and/or AV receivers come with a remote
capable of controlling multiple devices, and many bundled remotes are,
quite frankly, utter garbage.
This is precisely also my experience.
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line
).
I would not want to get to the point where the raw codes are used as a
primary data source.
The key interface is not flexible enough at present.
Again, I would prefer to keep EV_KEY/KEY_* as the primary event type for
keys and buttons on all devices.
Primary, I think so.
--
Krzysztof
a transmitter.
I say the transmitter is not an input device, they are completely
independent functions. I can't see any reason to try and fit both in the
same interface - can you?
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message
by the driver, input interface) and to the
hw driver. It would have to enable and call the required protocol
decoders (based on the keymap loaded).
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo
.
I briefly though about such possibility, but dismissed it with
assumption that we won't transmit the same codes (including key codes)
that we receive.
Perhaps I'm wrong.
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message
the relevant info only.
--
Krzysztof Halasa
--
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
: time=1248041061.007858 mode=0x020 in=0x000
out=0x020 [GPIO18 IRQ]
saa7133[0] GPIO: time=1248041061.009672 mode=0x020 in=0x004
out=0x020 [GPIO18 IRQ]
If you send all of that to me I should be able to figure out the code used.
--
Krzysztof Halasa
diff --git a/drivers
the output of dmesg(after modprobe and after a button is pressed)
I think we should add something printing changes on the GPIO line (and
current time). That should be easy, will try to have something soon.
That would show what code exactly a remote is using, at last.
--
Krzysztof Halasa
.
--
Krzysztof Halasa
--
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
, with LIRC daemon or
something similar. The current code only supports one RC5 group code
for each input (i.e., one RC or RC mode).
I'm attaching a test patch for 1 and 3. It's incomplete, breaks
bttv, but it currently works with my Philips RC and Super 007 DVB-T
board.
--
Krzysztof Halasa
ir_codes_rc5_tv[IR_KEYTAB_SIZE];
extern IR_KEYTAB_TYPE ir_codes_winfast[IR_KEYTAB_SIZE];
extern IR_KEYTAB_TYPE ir_codes_pinnacle_color[IR_KEYTAB_SIZE];
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord
68 matches
Mail list logo
