Nabble - LIRC

Devinput problems

2008-09-06T16:47:38Z

Hi everyone,

I have a problem with my TT S2-3200 IR receiver. It works, I can cat /dev/input/event7 just fine. But it acts as a keyboard, it will input stuff in terminals and whatnots.

"Great" for some, except this way, not all the keys work, and lirc doesn't want to "capture" this input device. Maybe because it's already used as a "keyboard"?

I'm not finding anything suspicious in the xorg.conf file.

Whenever I restart lirc, it won't give me any status messages.
irw will also refuse to connect or just complain about a missing file.

Because /etc/init.d/lirc & irw are acting so difficult, you would believe something is wrong with this build. But It's just mythbuntu, and it works GREAT on my AppleTV frontend running mythbuntu.

lirc just needs to grab control of my /dev/input/event7 device, how do I do that?

--

Met vriendelijke groeten,

Jelle De Loecker
Kipdola Studios - Tomberg

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Submitting lirc for kernel inclusion

2008-09-06T13:48:16Z

> On Thu, 2008-09-04 at 16:21 -0400, Jarod Wilson wrote:
> > So a good while back, I talked about submitting all the lirc drivers
> > upstream for inclusion in Linus' kernel... Well, I've been a bit busier
> > than expected all summer long, and only in this past week have really

I brought lirc into my tree....

I have it compiled in:
CC drivers/input/lirc/lirc_mceusb2.o
drivers/input/lirc/lirc_dev.c:742: warning: 'lirc_dev_init' defined but not used
Probably needs a #ifdef MODULE

It also defaulted in kconfig to having everything selected as a
module. Normal default is to have everything turned off.

I haven't tested anything yet.

--
Jon Smirl
jonsmirl@...

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

autostarting irexec, suspend button

2008-09-06T00:36:04Z

Hi all,

I'm trying to get my mythbuntu box to go to S3 suspend via remote. I've followed several sets of instructions, and have almost got it working.

I added my user (leeko) and the mythtv user (mythtv) to the sudoers file for /usr/sbin/pmi with the following lines:
mythtv ALL=NOPASSWD:/sbin/halt,/sbin/shutdown,/sbin/reboot,/bin/mount,/bin/umount,/usr/sbin/pmi
leeko ALL=NOPASSWD: /usr/sbin/pmi

I then created a suspend script (/home/leeko/scripts/suspend.sh):
------------------------
#!/bin/bash
sudo /usr/sbin/pmi action suspend
------------------------

Running the script with ./suspend.sh (logged in as leeko) works fine. If I start irexec manually, I can use the power button on my remote to suspend the computer. But, if I ask irexec to run at startup, it doesn't respond to the button press.

ps aux | grep irexec shows one running irexec process after startup. I am auto-starting it by adding the following line to /etc/rc.local:

usr/bin/irexec -d /home/leeko/.lircrc

I have also tried it without the -d flag, without specifying the config file, and with the config file in various different places. No change.

Can anyone suggest why this isn't working?

Thanks in advance,

Lee

Re: LIRC does not generate input events

2008-09-05T20:32:20Z

Thanks a lot for your reply, Chris,

2008/9/4 Christoph Bartelmus <lirc@...>:
> Do you get any output from /dev/input/event6 at all?
> If not, then the problem is not in LIRC, but the kernel driver which is
> part of the Linux kernel.

No, we tested that and there was no output.

> Have you made sure that you are using the correct config file?

I thought that, given there were no events coming through, the config
file wouldn't matter - is that the case? I selected my remote in the
Mythbuntu Control Centre GUI, but I'm pretty new to all of this...

Thanks again - any help with figuring out where my bug is would be appreciated!

Regards,

Aaron

--
FSF Associate Member: 5632
http://www.fsf.org

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Submitting lirc for kernel inclusion

2008-09-05T13:08:13Z

On 05 Sep 2008 21:10:00 +0200, Christoph Bartelmus <lirc@...> wrote:

> Hi!
>
> Jon Smirl "jonsmirl@..." wrote:
>
> > On 05 Sep 2008 19:12:00 +0200, Christoph Bartelmus <lirc@...>
>
> >> Jon Smirl "jonsmirl@..." wrote:
> >>>>> Has LIRC been modified to work with evdev?
> >> No, because it's not possible. See [1].
>
> > I believe it is possible to define your own event types in evdev.
> > You'd make new types for the LIRC data. These messages would match the
> > existing lirc interface. Some code will need to be added to evdev to
> > do this.
> >
> > evdev is there is make sure everything ends up in user space in the
> > right order. If you click the mouse before hitting the remote button,
> > evdev makes sure they arrive in that order. If you are using two
> > different devices and processes, the order the input is received will
> > be random.
>
>
> I'm not sure if you really know how the LIRC interface really looks like.
> Remote button presses are not single events in the LIRC interface.
>
> So just to start with, how would I map the LIRC ioctls defined in lirc.h
> to evdev?

It's not a five minute exercise to integrate LIRC into evdev. I can
look at it as time permits over the next few weeks. I need to add LIRC
support via an interrupting GPIO pin for the hardware I'm working on.

It is not a requirement to utilize for HI devices to use evdev but
using it fixes a lot of problems with event ordering, partial messages
and apps grabbing the device. I believe it would be good to integrate
LIRC (and anything else generating HI events) into the evdev queue.
The old /dev/mouse and /dev/kbd devices caused all sorts of problems
inside of X.

Keypresses are not single events either, there is key up/down/repeat.
And you're right, I don't know the details of what is being passed
through /dev/lirc.

I don't believe integrating with evdev is a requirement for getting
the drivers into the kernel.

>
> [...]
>
> >>> Long run lirc should shift to evdev. There's no reason for it to have
> >>> it's own private interface.
> >>
> >> Don't know why this is popping up regularly, but LIRC requires it's own
> >> interface.
> >> If someone wants to convice me of the opposite, please convert lirc_serial
> >> to use the evdev interface.
>
>
> Again, please show me how to convert lirc_serial to the evdev interface.
>
>
> Christoph
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>

--
Jon Smirl
jonsmirl@...

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Submitting lirc for kernel inclusion

2008-09-05T12:10:00Z

Hi!

Jon Smirl "jonsmirl@..." wrote:
> On 05 Sep 2008 19:12:00 +0200, Christoph Bartelmus <lirc@...>
>> Jon Smirl "jonsmirl@..." wrote:
>>>>> Has LIRC been modified to work with evdev?
>> No, because it's not possible. See [1].

> I believe it is possible to define your own event types in evdev.
> You'd make new types for the LIRC data. These messages would match the
> existing lirc interface. Some code will need to be added to evdev to
> do this.
>
> evdev is there is make sure everything ends up in user space in the
> right order. If you click the mouse before hitting the remote button,
> evdev makes sure they arrive in that order. If you are using two
> different devices and processes, the order the input is received will
> be random.

I'm not sure if you really know how the LIRC interface really looks like.
Remote button presses are not single events in the LIRC interface.

So just to start with, how would I map the LIRC ioctls defined in lirc.h
to evdev?

[...]
>>> Long run lirc should shift to evdev. There's no reason for it to have
>>> it's own private interface.
>>
>> Don't know why this is popping up regularly, but LIRC requires it's own
>> interface.
>> If someone wants to convice me of the opposite, please convert lirc_serial
>> to use the evdev interface.

Again, please show me how to convert lirc_serial to the evdev interface.

Christoph

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Submitting lirc for kernel inclusion

2008-09-05T10:47:57Z

On 05 Sep 2008 19:12:00 +0200, Christoph Bartelmus <lirc@...> wrote:
> Hi!
>
> Jon Smirl "jonsmirl@..." wrote:
> [...]
>
> >>> Has LIRC been modified to work with evdev?
>
>
> No, because it's not possible. See [1].

I believe it is possible to define your own event types in evdev.
You'd make new types for the LIRC data. These messages would match the
existing lirc interface. Some code will need to be added to evdev to
do this.

evdev is there is make sure everything ends up in user space in the
right order. If you click the mouse before hitting the remote button,
evdev makes sure they arrive in that order. If you are using two
different devices and processes, the order the input is received will
be random.

Once these events are in user space the receiving app would call a
LIRC library function to translate them.

evdev was created to fix ordering problems between the mouse and keyboard.

>
>
> >> Not that I'm aware of. First up, evdev needs to actually be completely
> >> usable -- Fedora 9 was initially planning to ship w/it on by default,
> >> but it caused too many problems, we're trying again with Fedora 10
> >> (aided by the fact we've hired Peter Hutterer).
> >>
> >>> Is there still a need for the lirc device?
>
> > Long run lirc should shift to evdev. There's no reason for it to have
> > it's own private interface.
>
>
> Don't know why this is popping up regularly, but LIRC requires it's own
> interface.
> If someone wants to convice me of the opposite, please convert lirc_serial
> to use the evdev interface.
>
> Christoph
>
> 1: http://sourceforge.net/mailarchive/message.php?msg_id=AAryKgq9UOB%40bartelmus.de
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>

Re: Submitting lirc for kernel inclusion

2008-09-05T10:12:00Z

Hi!

Jon Smirl "jonsmirl@..." wrote:
[...]
>>> Has LIRC been modified to work with evdev?

No, because it's not possible. See [1].

>> Not that I'm aware of. First up, evdev needs to actually be completely
>> usable -- Fedora 9 was initially planning to ship w/it on by default,
>> but it caused too many problems, we're trying again with Fedora 10
>> (aided by the fact we've hired Peter Hutterer).
>>
>>> Is there still a need for the lirc device?

> Long run lirc should shift to evdev. There's no reason for it to have
> it's own private interface.

Don't know why this is popping up regularly, but LIRC requires it's own
interface.
If someone wants to convice me of the opposite, please convert lirc_serial
to use the evdev interface.

Christoph

1: http://sourceforge.net/mailarchive/message.php?msg_id=AAryKgq9UOB%40bartelmus.de

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Submitting lirc for kernel inclusion

2008-09-04T23:58:00Z

Hi!

Jarod Wilson "jarod@..." wrote:
[...]
> spitting out no errors and only four warnings (about use of cvs keyword
> markers, which we can't drop yet).

sed --expression="s/\"\$Revision: $[0-9\.]*$ \$\"/\"\1\"/g"

[...]
> series to lkml no later than this weekend, after smoke-testing a number
> of drivers one last time. The current git tree can be found here:

I plan to commit a bugfix for this one soon:
http://sourceforge.net/tracker/index.php?func=detail&aid=1868795&group_id=5444&atid=105444

> Now, primarily targeted at Chrisoph, I have a few questions...
>
> 1) the git tree we've been working on has diverged a bit from lirc cvs.
> Should I prepare a patch or patches to be committed back into lirc cvs?

Yes, please.

> 2) if yes to #1, do we really truly want cvs to continue to be the
> canonical upstream for the lirc drivers?

I will continue using CVS. I'm fully aware, that by Linus' definition: I'm
stupid.

> 3) if yes to #2, can I possibly get cvs commit access to speed along the
> process of sync'ing git and cvs?

What's your SF account?

> 4) also if yes to #2, did the 'export to git' script I posted a while
> back seem like a good idea, or would it be better to just manually sync
> cvs and git?

The script seemed to work good enough, so I would like to use it in the
CVS -> git direction. Probably there will be no way around merging
manually in the opposite direction sometimes.
In the long run, when the drivers are included in the kernel, I would like
to stop maintaining the drivers in CVS altogether.

> 5) who should be listed as the Maintainer(s) for the in-kernel lirc
> drivers? I'm happy to have it be me, but Christoph, its your baby.

Whoever thinks he has time to do the job. I definitely don't want to stand
in the first line here...

Christoph

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Suggestions on Transmitters

2008-09-04T20:53:13Z

I've seen some of the devices listed on the LIRC website for both
transmitters and receivers. I've never done anything with IR on Linux,
but now I'd like to set up a system using my Nokia N770 Internet
tablet. I figure I could write a GUI on my computer that I access
through SSH and pull up on my N770 and use it as a universal remote
where I can put all the buttons where I want them and don't have to
switch from one device to another.

I saw one USB transceiver, for example, that claims a range of only 10
feet. I have a few devices on a shelf and about 5 feet away is the
sound system and then another 2 feet to the TV, or rather, the IR
receiver on the TV. I'd like to either use one transmitter that I
could mount on the ceiling or far wall that would cover that whole area
(which would also help if I ever moved the DVR and other devices to the
other side of the TV) or it might be possible, if everything is small
enough and only needs minimal cables, to make a long cable with IR LEDs
at at least three points along the cable (which would probably be about
12 feet long from computer connection to the last LED).

By looking over the LIRC site and links, it looks like a lot of people
using LIRC are doing hardware hacking, which I haven't done in so long
I can't remember much of it.

Can a serial port on the average computer drive 3-5 IR LEDs on a cable
as long as 12-15 feet? Would there be problems with the LEDs having to
be real close to the receivers on the devices?

Also, can someone recommend a good transmitter with a range of 15-18
feet? Or am I better off building the cable?

I'm brand new at this and definitely don't want to get bogged down in
recreating the wheel and I'm sure others have done similar things, so
I'm open to any comments or suggestions on using transmitters to
control several devices. (If it matters, I have a DVR, DVD, Squeezebox
(plays music over wifi from my server), sound system, and TV.)

Thanks for any help or suggestions!

Hal

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Submitting lirc for kernel inclusion

2008-09-04T20:01:37Z

On Thu, 2008-09-04 at 22:43 -0400, Jon Smirl wrote:

> > > Has LIRC been modified to work with evdev?
> >
> > Not that I'm aware of. First up, evdev needs to actually be completely
> > usable -- Fedora 9 was initially planning to ship w/it on by default,
> > but it caused too many problems, we're trying again with Fedora 10
> > (aided by the fact we've hired Peter Hutterer).
> >
> > > Is there still a need for the lirc device?
>
> Long run lirc should shift to evdev. There's no reason for it to have
> it's own private interface.

Works for me. Lets get it in first though. ;)

> > [...] My personal preference would be to
> > only maintain them in git, but that shuts out people who insist on
> > running ancient kernels. :)
>
> That is not entirely true, it only shuts out people running ancient
> kernels from getting brand new drivers.

Yeah, that was more what I meant.

> People running ancient kernels
> still have their ancient drivers. Most of the hardware in the kernel
> is supported this way.

Yep, I'm painfully aware of that, courtesy of being in the enterprise
kenrel group at Red Hat, where we backport the kitchen sink for new
hardware support into much older kernels...

For the most part, you're preaching to the choir, its Christoph we need
to talk into only maintaining the drivers in git. :)

--
Jarod Wilson
jarod@...

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Submitting lirc for kernel inclusion

2008-09-04T19:43:06Z

On 9/4/08, Jarod Wilson <jarod@...> wrote:

> On Thu, 2008-09-04 at 20:06 -0400, Jon Smirl wrote:
> > On 9/4/08, Jarod Wilson <jarod@...> wrote:
> > > Meant to include Janne on the cc list, please keep him in the loop.
>
>
> nb: Janne's actually on the list now.
>
>
> > > On Thu, 2008-09-04 at 16:21 -0400, Jarod Wilson wrote:
> > > > So a good while back, I talked about submitting all the lirc drivers
> > > > upstream for inclusion in Linus' kernel... Well, I've been a bit busier
> > > > than expected all summer long, and only in this past week have really
> > > > gotten back on the ball. Myself and Janne Grunau have been going back
> > > > over the latest checkpatch output, and as of this afternoon, have it
> > > > spitting out no errors and only four warnings (about use of cvs keyword
> > > > markers, which we can't drop yet). My intention is to submit a patch
> > > > series to lkml no later than this weekend, after smoke-testing a number
> > > > of drivers one last time. The current git tree can be found here:
> >
> > Has LIRC been modified to work with evdev?
>
>
> Not that I'm aware of. First up, evdev needs to actually be completely
> usable -- Fedora 9 was initially planning to ship w/it on by default,
> but it caused too many problems, we're trying again with Fedora 10
> (aided by the fact we've hired Peter Hutterer).
>
> > Is there still a need for the lirc device?

Long run lirc should shift to evdev. There's no reason for it to have
it's own private interface.

>
>
> Yes, definitely still a need right now. Some of the usb-based devices
> should ultimately be converted to userspace drivers, but someone needs
> to actually do that. In the mean time, we've got functional kernel-space
> drivers.
>
>
> > If sticking with CVS, make sure there aren't any CVS keywords in the
> > files submitted to kernel git. They cause pointless noise in the git
> > kernel history.
>
>
> Yep, long-term, that's part of the plan. My current tree has only 4
> left. Wanted to figure out what we're doing w/maintenance first.
>
>
> > If sticking with CVS, how are you going to handle CVS having support
> > for multiple kernel versions, and the git version only supporting a
> > single version? This is a pain in DRM drivers and it has to be
> > stripped out every time code is submitted upstream. Very few kernel
> > drivers are maintained outside of the main kernel trees.
>
>
> This part is sort of up to Christoph. My personal preference would be to
> only maintain them in git, but that shuts out people who insist on
> running ancient kernels. :)

That is not entirely true, it only shuts out people running ancient
kernels from getting brand new drivers. People running ancient kernels
still have their ancient drivers. Most of the hardware in the kernel
is supported this way.

DRM is one exception, but that is driven more by the fact that is used
in BSD instead of the need to support ancient kernels with new
drivers. Are there others? dvb?

Broad use of git is really reducing the justifications for supporting
ancient kernels. It is very easy now for LIRC to have it's own git
tree. Building a new kernel only takes a few minutes. If you're smart
enough to want to update the version of your LIRC driver you should be
smart enough to update your kernel too.

Another reason for leaving things in CVS is when some of the
developers won't use git. I don't know if that's a problem on LIRC.

> Based on some discussion with a v4l/dvb person or two, I hacked together
> a script that takes the cvs bits and exports them into a git tree, part
> of which is some fugly passes over the code with unifdef to yank the
> compat stuff. It more or less works, so long as the compat stuff is
> properly #ifdef'd.

--
Jon Smirl
jonsmirl@...

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Submitting lirc for kernel inclusion

2008-09-04T19:27:59Z

On Thu, 2008-09-04 at 20:06 -0400, Jon Smirl wrote:
> On 9/4/08, Jarod Wilson <jarod@...> wrote:
> > Meant to include Janne on the cc list, please keep him in the loop.

nb: Janne's actually on the list now.

> > On Thu, 2008-09-04 at 16:21 -0400, Jarod Wilson wrote:
> > > So a good while back, I talked about submitting all the lirc drivers
> > > upstream for inclusion in Linus' kernel... Well, I've been a bit busier
> > > than expected all summer long, and only in this past week have really
> > > gotten back on the ball. Myself and Janne Grunau have been going back
> > > over the latest checkpatch output, and as of this afternoon, have it
> > > spitting out no errors and only four warnings (about use of cvs keyword
> > > markers, which we can't drop yet). My intention is to submit a patch
> > > series to lkml no later than this weekend, after smoke-testing a number
> > > of drivers one last time. The current git tree can be found here:
>
> Has LIRC been modified to work with evdev?

Not that I'm aware of. First up, evdev needs to actually be completely
usable -- Fedora 9 was initially planning to ship w/it on by default,
but it caused too many problems, we're trying again with Fedora 10
(aided by the fact we've hired Peter Hutterer).

> Is there still a need for the lirc device?

Yes, definitely still a need right now. Some of the usb-based devices
should ultimately be converted to userspace drivers, but someone needs
to actually do that. In the mean time, we've got functional kernel-space
drivers.

> If sticking with CVS, make sure there aren't any CVS keywords in the
> files submitted to kernel git. They cause pointless noise in the git
> kernel history.

Yep, long-term, that's part of the plan. My current tree has only 4
left. Wanted to figure out what we're doing w/maintenance first.

> If sticking with CVS, how are you going to handle CVS having support
> for multiple kernel versions, and the git version only supporting a
> single version? This is a pain in DRM drivers and it has to be
> stripped out every time code is submitted upstream. Very few kernel
> drivers are maintained outside of the main kernel trees.

This part is sort of up to Christoph. My personal preference would be to
only maintain them in git, but that shuts out people who insist on
running ancient kernels. :)

Based on some discussion with a v4l/dvb person or two, I hacked together
a script that takes the cvs bits and exports them into a git tree, part
of which is some fugly passes over the code with unifdef to yank the
compat stuff. It more or less works, so long as the compat stuff is
properly #ifdef'd.

--
Jarod Wilson
jarod@...

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Submitting lirc for kernel inclusion

2008-09-04T19:18:43Z

On Thu, 2008-09-04 at 18:40 -0400, Sam Varshavchik wrote:

> Jarod Wilson writes:
>
> > Meant to include Janne on the cc list, please keep him in the loop.
> >
> > On Thu, 2008-09-04 at 16:21 -0400, Jarod Wilson wrote:
> >> So a good while back, I talked about submitting all the lirc drivers
> >> upstream for inclusion in Linus' kernel... Well, I've been a bit busier
>
> Aside from the things you've mentioned, you might want to know -- if you are
> not already -- that lirc kernel modules have been included in Fedora kernels
> for some time now. And I'd be surprised if most of the other distros do not
> already do the same, although I know only about Fedora.

Heh, as Tim already pointed out, I'm the one who put the patch into the
Fedora kernels in the first place, so yeah, I know. :)

> That's always a good argument to state, when asking to be added to upstream.

Yep, I'll definitely be noting that both Fedora and Ubuntu have been
carrying lirc patches for some time now.

> >> 5) who should be listed as the Maintainer(s) for the in-kernel lirc
> >> drivers? I'm happy to have it be me, but Christoph, its your baby.
>
> This is just a suggestion. Based solely on my observations, I would suggest
> putting down a mailing list address that includes all the key people.

Might not be a bad idea.

--
Jarod Wilson
jarod@...

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Submitting lirc for kernel inclusion

2008-09-04T17:06:24Z

On 9/4/08, Jarod Wilson <jarod@...> wrote:

> Meant to include Janne on the cc list, please keep him in the loop.
>
>
> On Thu, 2008-09-04 at 16:21 -0400, Jarod Wilson wrote:
> > So a good while back, I talked about submitting all the lirc drivers
> > upstream for inclusion in Linus' kernel... Well, I've been a bit busier
> > than expected all summer long, and only in this past week have really
> > gotten back on the ball. Myself and Janne Grunau have been going back
> > over the latest checkpatch output, and as of this afternoon, have it
> > spitting out no errors and only four warnings (about use of cvs keyword
> > markers, which we can't drop yet). My intention is to submit a patch
> > series to lkml no later than this weekend, after smoke-testing a number
> > of drivers one last time. The current git tree can be found here:

Has LIRC been modified to work with evdev? Is there still a need for
the lirc device?

If sticking with CVS, make sure there aren't any CVS keywords in the
files submitted to kernel git. They cause pointless noise in the git
kernel history.

If sticking with CVS, how are you going to handle CVS having support
for multiple kernel versions, and the git version only supporting a
single version? This is a pain in DRM drivers and it has to be
stripped out every time code is submitted upstream. Very few kernel
drivers are maintained outside of the main kernel trees.

> >
> > http://git.wilsonet.com/linux-2.6-lirc.git/
> >
> > (also git-clone-able at git://git.wilsonet.com/linux-2.6-lirc.git/)
> >
> >
> > Now, primarily targeted at Chrisoph, I have a few questions...
> >
> > 1) the git tree we've been working on has diverged a bit from lirc cvs.
> > Should I prepare a patch or patches to be committed back into lirc cvs?
> >
> > 2) if yes to #1, do we really truly want cvs to continue to be the
> > canonical upstream for the lirc drivers?
> >
> > 3) if yes to #2, can I possibly get cvs commit access to speed along the
> > process of sync'ing git and cvs?
> >
> > 4) also if yes to #2, did the 'export to git' script I posted a while
> > back seem like a good idea, or would it be better to just manually sync
> > cvs and git?
> >
> > 5) who should be listed as the Maintainer(s) for the in-kernel lirc
> > drivers? I'm happy to have it be me, but Christoph, its your baby.
> >
> >
> >
>
>
> --
> Jarod Wilson
> jarod@...
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>

Re: Submitting lirc for kernel inclusion

2008-09-04T16:20:21Z

On Thu, 04 Sep 2008 18:40:45 -0400 Sam Varshavchik
<mrsam@...> wrote:

> Jarod Wilson writes:
>
> > Meant to include Janne on the cc list, please keep him in the loop.
> >
> > On Thu, 2008-09-04 at 16:21 -0400, Jarod Wilson wrote:
> >> So a good while back, I talked about submitting all the lirc
> >> drivers upstream for inclusion in Linus' kernel... Well, I've been
> >> a bit busier
>
> Aside from the things you've mentioned, you might want to know -- if
> you are not already -- that lirc kernel modules have been included in
> Fedora kernels for some time now. And I'd be surprised if most of the
> other distros do not already do the same, although I know only about
> Fedora.
>

<ahem>

https://www.redhat.com/archives/fedora-kernel-list/2007-August/msg00147.html

;)

-Tim

--
CAPS LOCK IS THE CRUISE CONTROL OF AWESOMNESS

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

FastMedia remote, .lircrc escape code

2008-09-04T15:46:28Z

Hi all,

I am setting up a packard bell fastmedia remote, for use with mythtv
(mythbuntu 8.04). I'm using the lircd.conf as follows:

begin remote

name PackBell
bits 15
flags SPACE_ENC|CONST_LENGTH
eps 30
aeps 100

header 9065 4500
one 597 532
zero 597 1643
ptrail 597
pre_data_bits 16
pre_data 0xF708
post_data_bits 1
post_data 0x0
gap 107000
repeat_bit 0
repeat 9050 2250

begin codes
Help 0x0000000000006F90
Phone 0x0000000000004FB0
Message 0x0000000000006E91
SRS 0x0000000000004EB1
CD 0x0000000000002FD0
Aux1 0x0000000000000FF0
Aux2 0x0000000000002ED1
Aux3 0x0000000000000EF1
LMB 0x00000000000023DC
RMB 0x000000000000639C
Up 0x00000000000037C8
Down 0x00000000000057A8
Left 0x0000000000007788
Right 0x00000000000017E8
Menu 0x0000000000007B84
Mute 0x0000000000003BC4
Enter 0x00000000000047B8
CHUp 0x00000000000027D8
CHDown 0x0000000000006798
VolUp 0x0000000000005BA4
VolDown 0x0000000000001BE4
Display 0x00000000000007F8
One 0x0000000000005EA1
Two 0x0000000000001EE1
Three 0x0000000000000BF4
Four 0x0000000000007E81
Five 0x0000000000003EC1
Six 0x0000000000004BB4
Seven 0x0000000000005FA0
Eight 0x0000000000001FE0
Nine 0x0000000000002BD4
Zero 0x0000000000003FC0
Star 0x0000000000007F80
Hash 0x0000000000006B94
end codes

end remote
---------

It works fine in myth, to an extent. But, none of the buttons seem to
correspond to the "escape" key e.g cancelling a playing video back to
the menu.

I've added the escape key mapping to the .lircrc file, and it works fine
in menus (pressing SRS cancels back to the parent menu), but doesn't
work for cancelling out of a playing video/movie. Here's the full
contents of the .lircrc file (my entry is the last one):

leeko@leeko-media:~/.lirc$ cat mythtv
# LIRCRC Auto Generated by Mythbuntu Lirc Generator
# Author(s): Mario Limonciello, Nick Fox
# Created for use with Mythbuntu
begin
remote = PackBell
prog = mythtv
button = Seven
config = 7
repeat = 0
delay = 0
end

begin
remote = PackBell
prog = mythtv
button = Right
config = Right
repeat = 0
delay = 0
end

begin
remote = PackBell
prog = mythtv
button = Mute
config = |
repeat = 0
delay = 0
end

begin
remote = PackBell
prog = mythtv
button = One
config = 1
repeat = 0
delay = 0
end

begin
remote = PackBell
prog = mythtv
button = Down
config = Down
repeat = 0
delay = 0
end

begin
remote = PackBell
prog = mythtv
button = Zero
config = 0
repeat = 0
delay = 0
end

begin
remote = PackBell
prog = mythtv
button = Menu
config = M
repeat = 0
delay = 0
end

begin
remote = PackBell
prog = mythtv
button = Six
config = 6
repeat = 0
delay = 0
end

begin
remote = PackBell
prog = mythtv
button = Two
config = 2
repeat = 0
delay = 0
end

begin
remote = PackBell
prog = mythtv
button = CHDown
config = Down
repeat = 0
delay = 0
end

begin
remote = PackBell
prog = mythtv
button = CHUp
config = Up
repeat = 0
delay = 0
end

begin
remote = PackBell
prog = mythtv
button = VolDown
config = [
repeat = 0
delay = 0
end

begin
remote = PackBell
prog = mythtv
button = VolUp
config = ]
repeat = 0
delay = 0
end

begin
remote = PackBell
prog = mythtv
button = Five
config = 5
repeat = 0
delay = 0
end

begin
remote = PackBell
prog = mythtv
button = Display
config = I
repeat = 0
delay = 0
end

begin
remote = PackBell
prog = mythtv
button = Four
config = 4
repeat = 0
delay = 0
end

begin
remote = PackBell
prog = mythtv
button = Enter
config = Return
repeat = 0
delay = 0
end

begin
remote = PackBell
prog = mythtv
button = Up
config = Up
repeat = 0
delay = 0
end

begin
remote = PackBell
prog = mythtv
button = Nine
config = 9
repeat = 0
delay = 0
end

begin
remote = PackBell
prog = mythtv
button = Three
config = 3
repeat = 0
delay = 0
end

begin
remote = PackBell
prog = mythtv
button = Enter
config = Enter
repeat = 0
delay = 0
end

begin
remote = PackBell
prog = mythtv
button = Eight
config = 8
repeat = 0
delay = 0
end

begin
remote = PackBell
prog = mythtv
button = Left
config = Left
repeat = 0
delay = 0
end

begin
remote = PackBell
prog = mythtv
button = SRS
config = Escape
repeat = 0
delay = 0
end

------------------

Am I doing something wrong? If anyone could help me get the escape code
(or anything that'll do the same thing), I'd really appreciate it. Thanks!

Lee

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Submitting lirc for kernel inclusion

2008-09-04T15:40:45Z

Jarod Wilson writes:

> Meant to include Janne on the cc list, please keep him in the loop.
>
> On Thu, 2008-09-04 at 16:21 -0400, Jarod Wilson wrote:
>> So a good while back, I talked about submitting all the lirc drivers
>> upstream for inclusion in Linus' kernel... Well, I've been a bit busier

Aside from the things you've mentioned, you might want to know -- if you are
not already -- that lirc kernel modules have been included in Fedora kernels
for some time now. And I'd be surprised if most of the other distros do not
already do the same, although I know only about Fedora.

That's always a good argument to state, when asking to be added to upstream.

>> 5) who should be listed as the Maintainer(s) for the in-kernel lirc
>> drivers? I'm happy to have it be me, but Christoph, its your baby.

This is just a suggestion. Based solely on my observations, I would suggest
putting down a mailing list address that includes all the key people.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

attachment0 (204 bytes) Download Attachment

Re: Submitting lirc for kernel inclusion

2008-09-04T13:26:03Z

Meant to include Janne on the cc list, please keep him in the loop.

On Thu, 2008-09-04 at 16:21 -0400, Jarod Wilson wrote:

> So a good while back, I talked about submitting all the lirc drivers
> upstream for inclusion in Linus' kernel... Well, I've been a bit busier
> than expected all summer long, and only in this past week have really
> gotten back on the ball. Myself and Janne Grunau have been going back
> over the latest checkpatch output, and as of this afternoon, have it
> spitting out no errors and only four warnings (about use of cvs keyword
> markers, which we can't drop yet). My intention is to submit a patch
> series to lkml no later than this weekend, after smoke-testing a number
> of drivers one last time. The current git tree can be found here:
>
> http://git.wilsonet.com/linux-2.6-lirc.git/
>
> (also git-clone-able at git://git.wilsonet.com/linux-2.6-lirc.git/)
>
>
> Now, primarily targeted at Chrisoph, I have a few questions...
>
> 1) the git tree we've been working on has diverged a bit from lirc cvs.
> Should I prepare a patch or patches to be committed back into lirc cvs?
>
> 2) if yes to #1, do we really truly want cvs to continue to be the
> canonical upstream for the lirc drivers?
>
> 3) if yes to #2, can I possibly get cvs commit access to speed along the
> process of sync'ing git and cvs?
>
> 4) also if yes to #2, did the 'export to git' script I posted a while
> back seem like a good idea, or would it be better to just manually sync
> cvs and git?
>
> 5) who should be listed as the Maintainer(s) for the in-kernel lirc
> drivers? I'm happy to have it be me, but Christoph, its your baby.
>
>
>

--
Jarod Wilson
jarod@...

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Submitting lirc for kernel inclusion

2008-09-04T13:21:03Z

So a good while back, I talked about submitting all the lirc drivers
upstream for inclusion in Linus' kernel... Well, I've been a bit busier
than expected all summer long, and only in this past week have really
gotten back on the ball. Myself and Janne Grunau have been going back
over the latest checkpatch output, and as of this afternoon, have it
spitting out no errors and only four warnings (about use of cvs keyword
markers, which we can't drop yet). My intention is to submit a patch
series to lkml no later than this weekend, after smoke-testing a number
of drivers one last time. The current git tree can be found here:

http://git.wilsonet.com/linux-2.6-lirc.git/

(also git-clone-able at git://git.wilsonet.com/linux-2.6-lirc.git/)

Now, primarily targeted at Chrisoph, I have a few questions...

1) the git tree we've been working on has diverged a bit from lirc cvs.
Should I prepare a patch or patches to be committed back into lirc cvs?

2) if yes to #1, do we really truly want cvs to continue to be the
canonical upstream for the lirc drivers?

3) if yes to #2, can I possibly get cvs commit access to speed along the
process of sync'ing git and cvs?

4) also if yes to #2, did the 'export to git' script I posted a while
back seem like a good idea, or would it be better to just manually sync
cvs and git?

5) who should be listed as the Maintainer(s) for the in-kernel lirc
drivers? I'm happy to have it be me, but Christoph, its your baby.

--
Jarod Wilson
jarod@...

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Wake-on-event from Serial Remote?

2008-09-03T13:38:58Z

Hi everyone,

Apologies if this has been answered - I didn't find anything when I searched.

I have purchased a hewlett-packard fastview Serial IR remote control and receiver, to use with my Mythbuntu 8.04 box (combined backend/frontend). I should receive it shortly.

I am trying to figure out whether this remote can be configured to bring the computer out of standby? I have managed to get mythbuntu to manually go to S3 standby when I click suspend. Eventually, I will try to get it to auto-standby when idle, but not at the moment (I know there are a whole host of issues with that).

Anyway, my issue is that I know I can assign the power button on the remote to execute a suspend.sh script (i.e. hitting power on the remote sends the pc to S3 suspend), but can I wake it back up again? My motherboard is an ECS l7vmm2 (I think version 1.0a, but I'm not sure). The specs say it supports wake-on-lan, but I'm not sure about wake-on-anything else... In the bios, there is an option for wake-on-pci event, and the note beside it says this is required for wake-on-usb to work. Does this also apply to serial receivers?

Certainly, pressing any keys on my keyboard, or moving the mouse, brings the comp out of S3.

Any help/advice you can offer would be much appreciated.

Regards,

Lee

lee_alkureishi@...

Try Facebook in Windows Live Messenger! Try it Now!
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Fedora Core 8 and Lirc problems

2008-09-03T13:33:00Z

Hi!

Justin "luitjens@..." wrote:

[...]
> mode2 -m gives some output but i'm not sure if it is valid. Here are 3
> presses of the up button:
>
> [root@freevo lirc-0.8.3]# mode2 -m
> 0-pulse 2609031-space
>
> 9000 4000 1000 1000 1000 2000
> 0 2000 1000 1000 1000 1000

The output is invalid.
The problem is that do_gettimeofday() stopped working properly in your
kernel. The resolution should be better then microseconds, but it seems to
be around 1 ms. Maybe it's just a special kernel setting that has changed
compared to earlier kernel versions.

Christoph

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Fedora Core 8 and Lirc problems

2008-09-03T13:21:26Z

Thanks for the information. For now i'm going to just stick with
0.8.2. Hopefully someone figures that out in the future.

Justin

Jarod Wilson wrote:

> On Wed, 2008-09-03 at 13:54 -0600, Justin wrote:
>
>> Here is the relevant part of modeprobe.conf
>>
>> alias char-major-61 lirc_serial
>> options lirc_serial irq=4 io=0x3f8
>> install lirc_serial /bin/setserial /dev/ttyS0 uart none ;\
>> /sbin/modprobe --ignore-install lirc_serial
>>
>
> On irc.freenode.net the other day, someone in #mythtv mentioned that
> post-0.8.3, lirc_serial was behaving badly for him as well. Apparently,
> you're supposed to be able to pass in all the params as module options
> instead of having to use setserial. Even then, I think he said it wasn't
> behaving for him for some reason. That's about all I know at this
> point...
>
> I really ought to get myself a serial receiver to try out.
>
>
>
>> Justin wrote:
>>
>>> I use lirc_serial. I use a simple rs232 serial receiver:
>>> http://www.irblaster.info/receiver.html.
>>>
>>>
>>>
>>> Jarod Wilson wrote:
>>>
>>>
>>>> On Wed, 2008-09-03 at 12:25 -0600, Justin wrote:
>>>>
>>>>
>>>>
>>>>> I was using kernel 2.6.25.14-69 and tried installing the latest modules
>>>>> on fedora core 8 (lirc-0.8.3). However those crashed so I then moved to
>>>>> an install from source lirc-0.8.3. This also crashed. If I remember
>>>>> correctly I then went back to kernel 2.6.23.15-137 with lirc-0.8.3 and
>>>>> it crashed. Finally I installed lirc-0.8.2 from source with kernel
>>>>> 2.6.23.15-137 and everything worked fine again.
>>>>>
>>>>>
>>>>>
>>>> Which lirc_foo kernel module drives your lirc device?
>>>>
>>>>
>>>> (Latest Fedora kernels + lirc_mceusb, lirc_mceusb2 and lirc_i2c all work
>>>> fine on my end, but that's all the receivers I've got).
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> Christoph Bartelmus wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Hi!
>>>>>>
>>>>>> Justin "luitjens@..." wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Today i decided to be brace and update a 6 month old build of fedora
>>>>>>> core 8. In the process lirc has stopped working for me. When I try to
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Which kernel driver and which kernel version are you using?
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>> -------------------------------------------------------------------------
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in the world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>
>>>
>
>
>

Re: Fedora Core 8 and Lirc problems

2008-09-03T13:07:55Z

On Wed, 2008-09-03 at 13:54 -0600, Justin wrote:
> Here is the relevant part of modeprobe.conf
>
> alias char-major-61 lirc_serial
> options lirc_serial irq=4 io=0x3f8
> install lirc_serial /bin/setserial /dev/ttyS0 uart none ;\
> /sbin/modprobe --ignore-install lirc_serial

On irc.freenode.net the other day, someone in #mythtv mentioned that
post-0.8.3, lirc_serial was behaving badly for him as well. Apparently,
you're supposed to be able to pass in all the params as module options
instead of having to use setserial. Even then, I think he said it wasn't
behaving for him for some reason. That's about all I know at this
point...

I really ought to get myself a serial receiver to try out.

> Justin wrote:
> > I use lirc_serial. I use a simple rs232 serial receiver:
> > http://www.irblaster.info/receiver.html.
> >
> >
> >
> > Jarod Wilson wrote:
> >
> >> On Wed, 2008-09-03 at 12:25 -0600, Justin wrote:
> >>
> >>
> >>> I was using kernel 2.6.25.14-69 and tried installing the latest modules
> >>> on fedora core 8 (lirc-0.8.3). However those crashed so I then moved to
> >>> an install from source lirc-0.8.3. This also crashed. If I remember
> >>> correctly I then went back to kernel 2.6.23.15-137 with lirc-0.8.3 and
> >>> it crashed. Finally I installed lirc-0.8.2 from source with kernel
> >>> 2.6.23.15-137 and everything worked fine again.
> >>>
> >>>
> >> Which lirc_foo kernel module drives your lirc device?
> >>
> >>
> >> (Latest Fedora kernels + lirc_mceusb, lirc_mceusb2 and lirc_i2c all work
> >> fine on my end, but that's all the receivers I've got).
> >>
> >>
> >>
> >>
> >>
> >>> Christoph Bartelmus wrote:
> >>>
> >>>
> >>>> Hi!
> >>>>
> >>>> Justin "luitjens@..." wrote:
> >>>>
> >>>>
> >>>>
> >>>>> Today i decided to be brace and update a 6 month old build of fedora
> >>>>> core 8. In the process lirc has stopped working for me. When I try to
> >>>>>
> >>>>>
> >>>>>
> >>>> Which kernel driver and which kernel version are you using?
> >>>>
> >>>>
> >>
> >>
> >>
> >
> >
> > -------------------------------------------------------------------------
> > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> > Build the coolest Linux based applications with Moblin SDK & win great prizes
> > Grand prize is a trip for two to an Open Source event anywhere in the world
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> >
>

Re: Fedora Core 8 and Lirc problems

2008-09-03T12:54:15Z

Here is the relevant part of modeprobe.conf

alias char-major-61 lirc_serial
options lirc_serial irq=4 io=0x3f8
install lirc_serial /bin/setserial /dev/ttyS0 uart none ;\
/sbin/modprobe --ignore-install lirc_serial

Thanks,
Justin

Justin wrote:

> I use lirc_serial. I use a simple rs232 serial receiver:
> http://www.irblaster.info/receiver.html.
>
>
>
> Jarod Wilson wrote:
>
>> On Wed, 2008-09-03 at 12:25 -0600, Justin wrote:
>>
>>
>>> I was using kernel 2.6.25.14-69 and tried installing the latest modules
>>> on fedora core 8 (lirc-0.8.3). However those crashed so I then moved to
>>> an install from source lirc-0.8.3. This also crashed. If I remember
>>> correctly I then went back to kernel 2.6.23.15-137 with lirc-0.8.3 and
>>> it crashed. Finally I installed lirc-0.8.2 from source with kernel
>>> 2.6.23.15-137 and everything worked fine again.
>>>
>>>
>> Which lirc_foo kernel module drives your lirc device?
>>
>>
>> (Latest Fedora kernels + lirc_mceusb, lirc_mceusb2 and lirc_i2c all work
>> fine on my end, but that's all the receivers I've got).
>>
>>
>>
>>
>>
>>> Christoph Bartelmus wrote:
>>>
>>>
>>>> Hi!
>>>>
>>>> Justin "luitjens@..." wrote:
>>>>
>>>>
>>>>
>>>>> Today i decided to be brace and update a 6 month old build of fedora
>>>>> core 8. In the process lirc has stopped working for me. When I try to
>>>>>
>>>>>
>>>>>
>>>> Which kernel driver and which kernel version are you using?
>>>>
>>>>
>>
>>
>>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>

Re: Fedora Core 8 and Lirc problems

2008-09-03T12:53:01Z

I use lirc_serial. I use a simple rs232 serial receiver:
http://www.irblaster.info/receiver.html.

Jarod Wilson wrote:

> On Wed, 2008-09-03 at 12:25 -0600, Justin wrote:
>
>> I was using kernel 2.6.25.14-69 and tried installing the latest modules
>> on fedora core 8 (lirc-0.8.3). However those crashed so I then moved to
>> an install from source lirc-0.8.3. This also crashed. If I remember
>> correctly I then went back to kernel 2.6.23.15-137 with lirc-0.8.3 and
>> it crashed. Finally I installed lirc-0.8.2 from source with kernel
>> 2.6.23.15-137 and everything worked fine again.
>>
>
> Which lirc_foo kernel module drives your lirc device?
>
>
> (Latest Fedora kernels + lirc_mceusb, lirc_mceusb2 and lirc_i2c all work
> fine on my end, but that's all the receivers I've got).
>
>
>
>
>> Christoph Bartelmus wrote:
>>
>>> Hi!
>>>
>>> Justin "luitjens@..." wrote:
>>>
>>>
>>>> Today i decided to be brace and update a 6 month old build of fedora
>>>> core 8. In the process lirc has stopped working for me. When I try to
>>>>
>>>>
>>> Which kernel driver and which kernel version are you using?
>>>
>
>
>
>

Re: Fedora Core 8 and Lirc problems

2008-09-03T11:40:55Z

On Wed, 2008-09-03 at 12:25 -0600, Justin wrote:
> I was using kernel 2.6.25.14-69 and tried installing the latest modules
> on fedora core 8 (lirc-0.8.3). However those crashed so I then moved to
> an install from source lirc-0.8.3. This also crashed. If I remember
> correctly I then went back to kernel 2.6.23.15-137 with lirc-0.8.3 and
> it crashed. Finally I installed lirc-0.8.2 from source with kernel
> 2.6.23.15-137 and everything worked fine again.

Which lirc_foo kernel module drives your lirc device?

(Latest Fedora kernels + lirc_mceusb, lirc_mceusb2 and lirc_i2c all work
fine on my end, but that's all the receivers I've got).

> Christoph Bartelmus wrote:
> > Hi!
> >
> > Justin "luitjens@..." wrote:
> >
> >> Today i decided to be brace and update a 6 month old build of fedora
> >> core 8. In the process lirc has stopped working for me. When I try to
> >>
> >
> > Which kernel driver and which kernel version are you using?

Re: Fedora Core 8 and Lirc problems

2008-09-03T11:25:48Z

I was using kernel 2.6.25.14-69 and tried installing the latest modules
on fedora core 8 (lirc-0.8.3). However those crashed so I then moved to
an install from source lirc-0.8.3. This also crashed. If I remember
correctly I then went back to kernel 2.6.23.15-137 with lirc-0.8.3 and
it crashed. Finally I installed lirc-0.8.2 from source with kernel
2.6.23.15-137 and everything worked fine again.

Thanks,
Justin

Christoph Bartelmus wrote:

> Hi!
>
> Justin "luitjens@..." wrote:
>
>> Today i decided to be brace and update a 6 month old build of fedora
>> core 8. In the process lirc has stopped working for me. When I try to
>>
>
> Which kernel driver and which kernel version are you using?
>
> Christoph
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>

Re: Fedora Core 8 and Lirc problems

2008-09-03T11:05:00Z

Hi!

Justin "luitjens@..." wrote:
> Today i decided to be brace and update a 6 month old build of fedora
> core 8. In the process lirc has stopped working for me. When I try to

Which kernel driver and which kernel version are you using?

Christoph

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/