Prev: x86, crypto, Use gas macro for PCLMULQDQ-NI and PSHUFB
Next: [patch 6/8] x86: UV - XPC NULL deref when mesq becomes empty.
From: Mauro Carvalho Chehab on 26 Nov 2009 08:30
Andy Walls wrote:
> On Mon, 2009-11-23 at 22:46 +0100, Krzysztof Halasa wrote:
>> lirc(a)bartelmus.de (Christoph Bartelmus) writes:
>>
>>>> I think we shouldn't at this time worry about IR transmitters.
>>> Sorry, but I have to disagree strongly.
>>> Any interface without transmitter support would be absolutely unacceptable
>>> for many LIRC users, including myself.
>> I don't say don't use 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?
>
> The underlying hardware need not be completely independent.
>
> For example, the CX2584[0123], CX2388[578], CX23418, and CX2310[012]
> chips have IR hardware that shares a common timing source, interrupt
> line, interrupt status register, etc, between IR Rx and Tx. They can
> also do things like loopback of Tx to Rx.
>
> That said, an underlying hardware implementation can be split up to user
> space with separate interfaces Tx and Rx. The underlying driver module
> would have to manage the dependencies. I would guess that would be
> easier for driver modules, if the userspace interfaces were designed
> with such combined IR Tx/Rx hardware in mind.

True, but, in the case of Rx, there are already API's for it. Tx case is
simpler, as we don't have any API for it yet.

I'm not sure if all the existing hardware for TX currently supports only
raw pulse/code sequencies, but I still think that, even on the Tx case,
it is better to send scancodes to the driver, and let it do the conversion
to raw pulse/code, if the hardware requires pulse/code instead of scancodes.

However, as we have green field,
I would add the protocol explicitly for each scancode to be transmitted, like:

struct ir_tx {
enum ir_protocol proto;
u32 scancode;
};

Eventually, we might have a protocol "raw" and some extra field to allow passing
a raw pulse/code sequence instead of a scancode.

Cheers,
Mauro.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Mauro Carvalho Chehab on 26 Nov 2009 09:00
Jarod Wilson wrote:
> On Nov 23, 2009, at 7:53 PM, Andy Walls wrote:
>
>> On Mon, 2009-11-23 at 22:11 +0100, Christoph Bartelmus wrote:
> ...
>> I generally don't understand the LIRC aversion I perceive in this thread
>> (maybe I just have a skewed perception). Aside for a video card's
>> default remote setup, the suggestions so far don't strike me as any
>> simpler for the end user than LIRC -- maybe I'm just used to LIRC. LIRC
>> already works for both transmit and receive and has existing support in
>> applications such as MythTV and mplayer.
>
> There's one gripe I agree with, and that is that its still not plug-n-play.
> Something where udev auto-loads a sane default remote config for say,
> mceusb transceivers, and the stock mce remote Just Works would be nice,
> but auto-config is mostly out the window the second you involve transmitters
> and universal remotes anyway.

For several devices, an udev rule that auto-loads a sane default keymap does work.
Of course, this won't cover 100% of the usages, and I lirc is a very good way
of covering the holes.

> But outside of that, I think objections are largely philosophical --
> in a nutshell, the kernel has an input layer, remotes are input devices,
> and lirc doesn't conform to input layer standards.

Yes. I think this is mainly the issue.

The other issue is how to migrate the existing drivers to a new API without
causing regressions. If we decide that IR's that receive raw pulse/code
should use the raw input interface, this means that a large task force will be
needed to convert the existing drivers to use it.

> I do understand that argument, I just don't currently agree that all IR must
> go through the input layer before the drivers are acceptable for upstream --
> especially since lircd can reinject decoded key presses into the input layer via uinput.

IMHO, there are some scenarios for an upcoming kernel IR raw input interface:

1) as a temporary solution for merging lirc drivers, knowing in advance that it will
be later converted to the standard input API;

2) as a raw interface for some weird usages, with its usage limited to just a
few device drivers;

3) as the solution for all IR's that produces pulse/code raw sequences;

For (1), while it may make sense, we'll be creating an userspace API that is
meant to be stable, knowing in advance that it will be removed in a close
future.

IMHO, we should avoid (2), since it will be hard to define what is the "limited
usage", and I bet that it will evolute to (3) in a long term.

For (3), we need to consider the migration of the existing drivers.

By discarding scenario (2), this means that, in the long term, we'll need to either
migrate all existing out-of-tree lirc drivers to the standard input API interface
(scenario 1) or to migrate the existing drivers to the raw input interface (scenario 3).

For me, scenario (1) is fine if we add the lirc drivers at drivers/staging.

>> I believe Jarod's intent is to have the LIRC components, that need to be
>> in kernel modules, moved into kernel mainline to avoid the headaches of
>> out of kernel driver maintenance. I'm not sure it is time well spent
>> for developers, or end users, to develop yet another IR receive
>> implementation in addition to the ones we suffer with now.
>
> Yeah, a fairly relevant factor in all this is that, despite not being in the linux
> kernel source tree proper-like, the lirc drivers and lirc have been in use for many
> years by lots of users. The likes of Fedora, Debian, Ubuntu, SUSE, Mandriva, etc.
> have all been shipping lirc drivers for years now. While lirc certainly isn't
> perfect (its not always the easiest thing for users to set up), it has actually
> proven itself pretty robust and useful in the field, once set up. The bulk of
> breakage in lirc I've personally had to deal with has mostly come in the
> form of kernel interface changes, which would definitely be mitigated by
> not having to maintain the drivers out-of-tree any longer.
>
> Now, I'm all for "improving" things and integrating better with the input
> subsystem, but what I don't really want to do is break compatibility with the
> existing setups on thousands (and thousands?) of MythTV boxes around the globe.
> The lirc userspace can be pretty nimble. If we can come up with a shiny new way
> that raw IR can be passed out through an input device, I'm pretty sure lirc
> userspace can be adapted to handle that. If a new input-layer-based transmit
> interface is developed, we can take advantage of that too. But there's already
> a very mature lirc interface for doing all of this. So why not start with adding
> things more or less as they exist right now and evolve the drivers into an
> idealized form? Getting *something* into the kernel in the first place is a
> huge step in that direction.

I agree. We should really move forward and add it to kernel as soon as possible,
and start to work on improving the IR support at the upstream kernel.

Jarold,

What do you think of adding lirc at staging while we discuss/improve the API's and lircd
support for the input event interface? Do you think this would work?

Cheers,
Mauro.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Mauro Carvalho Chehab on 26 Nov 2009 09:10
Krzysztof Halasa wrote:
> Andy Walls <awalls(a)radix.net> writes:
>
>> I would also note that RC-6 Mode 6A, used by most MCE remotes, was
>> developed by Philips, but Microsoft has some sort of licensing interest
>> in it and it is almost surely encumbered somwhow:
>
> I don't know about legal problems in some countries but from the
> technical POV handling the protocol in the kernel is more efficient
> or (/and) simpler.

A software licensing from Microsoft won't apply to Linux kernel, so I'm
assuming that you're referring to some patent that they could be filled
about RC6 mode 6A.

I don't know if is there any US patent pending about it (AFAIK, only US
accepts software patents), but there are some prior-art for IR key
decoding. So, I don't see what "innovation" RC6 would be adding.
If it is some new way to transmit waves, the patent issues
aren't related to software, and the device manufacturer had already handled
it when they made their devices. If it is just a new keytable, this issue
could be easily solved by loading the keytable via userspace.

Also, assuming that you can use the driver only with a hardware that comes
with a licensed software, the user has already the license for using it.

Do you have any details on what patents they are claiming?

Cheers,
Mauro.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Mauro Carvalho Chehab on 26 Nov 2009 09:30
Jarod Wilson wrote:
> On Nov 25, 2009, at 12:40 PM, Krzysztof Halasa wrote:
>
>> lirc(a)bartelmus.de (Christoph Bartelmus) writes:
>>
>>> I'm not sure what two ways you are talking about. With the patches posted
>>> by Jarod, nothing has to be changed in userspace.
>>> Everything works, no code needs to be written and tested, everybody is
>>> happy.
>> The existing drivers use input layer. Do you want part of the tree to
>> use existing lirc interface while the other part uses their own
>> in-kernel (badly broken for example) code to do precisely the same
>> thing?
>
> Took me a minute to figure out exactly what you were talking about. You're referring to the
> current in-kernel decoding done on an ad-hoc basis for assorted remotes
> bundled with capture devices, correct?

They are not limited to the currently bundled IR's, since almost all drivers allow
replacing the existing scancode/keycode table to a new onw.

> Admittedly, unifying those and the lirc driven devices hasn't really been on my radar.

It should be done. Having two ways for doing the same thing is not an option. We'll
need to unify them sooner or later. The sooner, the better.

>> We can have a good code for both, or we can end up with "badly broken"
>> media drivers and incompatible, suboptimal existing lirc interface
>> (though most probably much better in terms of quality, especially after
>> Jarod's work).
>
> Well, is there any reason most of those drivers with
> currently-in-kernel-but-badly-broken decoding can't be converted to
> use the lirc interface if its merged into the kernel?

> And/or, everything
> could converge on a new in-kernel decoding infra that wasn't badly broken.
> Sure, there may be two separate ways of doing essentially the same thing
> for a while, but meh. The lirc way works NOW for an incredibly wide
> variety of receivers, transmitters, IR protocols, etc.

Yes: the same drivers support both pulse/space and in-hardware scancode conversion.
In order to use the raw pulse/space API, they'll need to generate pseudo pulse/space's.
This would be a dirty solution, IMHO.

Also, changing the drivers would not be that easy, since it will require lots of
tests with IR's and devices that the developers won't have. This is a weaker argument,
since no matter what decided, we'll need to change the drivers code (on lirc drivers
or on the in-kernel drivers) even without having all hardware available.

> I do concur that Just Works decoding for bundled remotes w/o having to
> configure anything would be nice, and one way to go about doing that
> certainly is via in-kernel IR decoding. But at the same time, the second
> you want to use something other than a bundled remote, things fall down,
> and having to do a bunch of setkeycode ops seems less optimal than simply
> dropping an appropriate lircd.conf in place.

I don't see this as an issue. We have by far too much work to be done in kernelspace
than the changes that are needed on userspace.

Replace the entire scancode table with setkeycode ops is very fast, and needs to be
done only once, at lirc startup. Once you load the new IR code at the driver,
the kernel will send the new keycodes to lirc.

It doesn't seem hard to modify lirc to do read the lircd.conf table and replace the
IR scancodes at the in-kernel driver. It took me half an hour to write my own keycode
loader code, and you can use it as the basis for such feature:
http://linuxtv.org/hg/v4l-dvb/file/tip/v4l2-apps/util/keytable.c


Cheers,
Mauro.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Mauro Carvalho Chehab on 26 Nov 2009 11:10
Jarod Wilson wrote:

>> I guess the question is what is the interface we want the regular
>> userspace (i.e. not lircd) to use. Right now programs has to use 2
>> intercfaces - one lirc for dealing with remotes that are not using
>> the standard event interface and evdev for remotes using it as well
>> as the rest of the input devices.
>
> From the mythtv perspective, using the input layer could yield a better
> out-of-the-box experience -- users don't have to set up an lircrc mapping
> that converts key names as specified in lircd.conf into commands
> (key strokes, actually) that mythtv understands. For example, a button labeled "Play"
> in lircd.conf has to be mapped to 'p' in ~/.lircrc for mythtv to do the right
> thing with it. If everything came through the input layer, be that natively
> or via lircd's uinput reinjection, there would be no need to do that extra
> mapping step, mythtv would simply handle a KEY_PLAY event. So at worst,
> one manual mapping to do -- IR signal to standard button name in lircd.conf --
> instead of two. But the lircrc approach does also allow more flexibility,
> in that you can only have a certain app respond to a certain key, if so desired,
> and remap a key to a different function (KEY_RED, KEY_GREEN, KEY_BLUE, KEY_YELLOW
> -- what should their default functionality be? I know some users map a pair
> of those to mythtv's "skip to next commflag point" and "skip to prior commflag point").
>
> Unfortunately, mythtv currently doesn't handle KEY_PLAY, KEY_VOLUMEUP, etc., etc. at
> all right now, it operates purely on keys commonly found on a standard keyboard.
> Remedying that is on my TODO list for the next release, if I can carve out the time.

This discussion is a little OT from the API discussions, since it affects both out-of-the
box IR reception via input layer and lirc.

All media applications should be capable of handling the corresponding KEY_PLAY, KEY_VOLUMEUP ...
keys without needing to do anything else than just handling the corresponding keycode.
You shouldn't need to start a daemon or doing anything else for this to work out-of-the-box.

They currently don't do it due to historic reasons (it is easier to let something else
remap KEY_PLAY into 'p' than to add the proper code there).

When using non-hot-pluggable devices where you're building a dedicated MCE hardware (this
is the common case of MythTV setups), things are not that bad, since, once you set your
hardware, it is done.

However, by looking on the number of different new devices, it seems that the most common
type of devices are the TV USB sticks. As they are hot pluggable, eventually users may
have more than one hardware and they expect that the IR layer will work equally on
all your devices.

The proper way for supporting it is to have a common application-agnostic keycode to indicate
the received events. For example, all IR's should produce KEY_CHANNELUP/KEY_CHANNELDOWN events
for changing the channels. Also, on a perfect world, lirc should send this event to the
multimedia application that handles TV when such key is pressed, instead of converting into
some other keycode. This prevents future problems if, for some reason, the application needs to
do something else with that key, or if the key has a different meaning on some different contexts.

For example, on some applications, KEY_UP/KEY_DOWN can mean to change a channel, but those keys
are also used for menu navigation. However, KEY_CHANNELUP has a clear unique meaning: to change a channel.
The expected behavior, from users perspective, is to mimic a TV box, where if you press channel UP
any open menu will be closed and the channel will be changed, but pressing UP key will
navigate at the menu. Well, if you map KEY_CHANNELUP as KEY_UP, you'll produce a different behavior.

Cheers,
Mauro.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11 12
Prev: x86, crypto, Use gas macro for PCLMULQDQ-NI and PSHUFB
Next: [patch 6/8] x86: UV - XPC NULL deref when mesq becomes empty.