Menu
▾
▴
lirc-list
|
From: Jarod W. <ja...@wi...> - 2011-03-25 22:41:17
|
Its been almost five months since the only pre-0.9.0 snapshot went out the door, and there hasn't been much of any complaints, and I've been meaning to push a release out for quite some time, so finally, here it is... http://sourceforge.net/projects/lirc/files/LIRC/0.9.0/lirc-0.9.0.tar.bz2/download The main goal behind this release is compatibility with all the lirc code that has been merged into the Linux kernel as of around 2.6.36 and on. I've also removed several drivers that I consider completely obsolete and will never update ever again, as they've been superseded by upstream kernel drivers. There will be more chopped out of 0.9.1 as well. :) I'll get 0.9.0 final packages into Fedora hopefully over the weekend, hopefully other distros will follow suit shortly thereafter... Changes since last release: * Remove mceusb, streamzap, it8x, ene0100 drivers, as they're now redundant with upstream kernel drivers * fix oops unplugging igorplugusb receiver while in use (special thanks to Timo Boettcher for providing hardware) * more error-checking for NULL irctl in various lirc_dev paths * add support for Monueal Moncaso IR to mplay driver (123justme) * add another PNP device ID to lirc_it87 (Jochen K?hner) * drop references to static chardev major number 61, we use dynamic * resync lirc_dev with what was merged in the kernel * reformat code using indent to look more like Linux kernel code * drop explicit support for kernels older than 2.6.18 * adapt to using lirc.h as merged in the upstream linux kernel * non-LONG_IR_CODE option dropped, its been the default for years * use portable type definitions all over the place * drop an old GLIBC work-around for printing 64-bit values * fix timing-specific repeat-after-release issue (Christoph Bartelmus) -- Jarod Wilson ja...@wi... |
|
From: Dale P. <DEP...@ed...> - 2011-03-28 01:52:43
|
On 03/25/11 18:41, Jarod Wilson wrote: <snip> > The main goal behind this release is compatibility with all the > lirc code that has been merged into the Linux kernel as of > around 2.6.36 and on. I've also removed several drivers that I > consider completely obsolete and will never update ever again, > as they've been superseded by upstream kernel drivers. There will > be more chopped out of 0.9.1 as well. :) Perhaps this is a good place/opportunity to ask this question. I'm using an mceusb IR receiver/remote on a dedicated mythfrontend machine. To make it more appliance-like with faster powerup I suspend instead of powering off. I haven't been able to wake-on-USB with any kernel after the 2.6.32 series. I'm currently running 2.6.32-gentoo-r27, and it and every kernel before that properly does wake-on-USB. No kernel beginning with 2.6.33 does, and that includes testing 2.6.38 this afternoon. It also includes both Gentoo and vanilla kernels. I ask here because you're about to remove the lirc drivers that I'm using, and I haven't been able to get myself up to 2.6.36 yet, though I'd really like to. I recognize that this issue is not core to lirc, though in the lirc community people may be more aware of this kind of problem and how to fix it. Everything in userspace remains unchanged between the various kernels, and when I build 2.6.33+ kernels I start with my 2.6.32 config and tweak the new stuff, but the old stuff is still essentially there. One note... My mceusb IR receiver has an LED that blinks when it receives a signal. When the system is suspended and I press the power button, that LED comes on solid until the system has wakened. When suspended with a 2.6.33+ kernel the LED doesn't come on, doesn't even blink when the power button is pressed. I can wake the system with the front-panel power button, in any case. Thanks for any pointers, Dale Pontius |
|
From: Paul B. <peb...@gm...> - 2011-03-28 16:53:47
|
On 3/27/2011 6:03 PM, Dale Pontius wrote:
> On 03/25/11 18:41, Jarod Wilson wrote:
> <snip>
>> The main goal behind this release is compatibility with all the
>> lirc code that has been merged into the Linux kernel as of
>> around 2.6.36 and on. I've also removed several drivers that I
>> consider completely obsolete and will never update ever again,
>> as they've been superseded by upstream kernel drivers. There will
>> be more chopped out of 0.9.1 as well. :)
>
> Perhaps this is a good place/opportunity to ask this question. I'm
> using an mceusb IR receiver/remote on a dedicated mythfrontend machine.
> To make it more appliance-like with faster powerup I suspend instead of
> powering off.
>
> I haven't been able to wake-on-USB with any kernel after the 2.6.32
> series. I'm currently running 2.6.32-gentoo-r27, and it and every
> kernel before that properly does wake-on-USB. No kernel beginning with
> 2.6.33 does, and that includes testing 2.6.38 this afternoon. It also
> includes both Gentoo and vanilla kernels.
>
> I ask here because you're about to remove the lirc drivers that I'm
> using, and I haven't been able to get myself up to 2.6.36 yet, though
> I'd really like to. I recognize that this issue is not core to lirc,
> though in the lirc community people may be more aware of this kind of
> problem and how to fix it.
>
> Everything in userspace remains unchanged between the various kernels,
> and when I build 2.6.33+ kernels I start with my 2.6.32 config and tweak
> the new stuff, but the old stuff is still essentially there.
>
> One note... My mceusb IR receiver has an LED that blinks when it
> receives a signal. When the system is suspended and I press the power
> button, that LED comes on solid until the system has wakened. When
> suspended with a 2.6.33+ kernel the LED doesn't come on, doesn't even
> blink when the power button is pressed. I can wake the system with the
> front-panel power button, in any case.
You need to be sure that the power is provided to the device. In the
past, this was done through /proc/acpi/wakeup. However, with more recent
kernels, this is done through /sys/devices/*/wakeup. I use the following
script to enable wakeup when the remote is detected by udev:
#!/bin/sh
################################################################################
# wakeup_enable
################################################################################
devpath=`readlink -f "/sys/${DEVPATH}"`
while echo "${devpath}" | /bin/grep -q '^/sys/devices/' > /dev/null 2>&1
; do
if test -e "${devpath}/power/wakeup" ; then
state=`cat "${devpath}/power/wakeup"`
if test "x${state}" = "xdisabled" ; then
echo "enabled" > "${devpath}/power/wakeup"
fi
fi
devpath=`dirname "${devpath}"`
done
exit 0
|
|
From: Dale P. <DEP...@ed...> - 2011-03-29 00:43:31
|
On 03/28/11 12:53, Paul Bender wrote:
> On 3/27/2011 6:03 PM, Dale Pontius wrote:
>> On 03/25/11 18:41, Jarod Wilson wrote:
>> <snip>
>>> The main goal behind this release is compatibility with all the
>>> lirc code that has been merged into the Linux kernel as of
>>> around 2.6.36 and on. I've also removed several drivers that I
>>> consider completely obsolete and will never update ever again,
>>> as they've been superseded by upstream kernel drivers. There will
>>> be more chopped out of 0.9.1 as well. :)
>>
>> Perhaps this is a good place/opportunity to ask this question. I'm
>> using an mceusb IR receiver/remote on a dedicated mythfrontend machine.
>> To make it more appliance-like with faster powerup I suspend instead of
>> powering off.
>>
>> I haven't been able to wake-on-USB with any kernel after the 2.6.32
>> series. I'm currently running 2.6.32-gentoo-r27, and it and every
>> kernel before that properly does wake-on-USB. No kernel beginning with
>> 2.6.33 does, and that includes testing 2.6.38 this afternoon. It also
>> includes both Gentoo and vanilla kernels.
>>
>> I ask here because you're about to remove the lirc drivers that I'm
>> using, and I haven't been able to get myself up to 2.6.36 yet, though
>> I'd really like to. I recognize that this issue is not core to lirc,
>> though in the lirc community people may be more aware of this kind of
>> problem and how to fix it.
>>
>> Everything in userspace remains unchanged between the various kernels,
>> and when I build 2.6.33+ kernels I start with my 2.6.32 config and tweak
>> the new stuff, but the old stuff is still essentially there.
>>
>> One note... My mceusb IR receiver has an LED that blinks when it
>> receives a signal. When the system is suspended and I press the power
>> button, that LED comes on solid until the system has wakened. When
>> suspended with a 2.6.33+ kernel the LED doesn't come on, doesn't even
>> blink when the power button is pressed. I can wake the system with the
>> front-panel power button, in any case.
>
> You need to be sure that the power is provided to the device. In the
> past, this was done through /proc/acpi/wakeup. However, with more recent
> kernels, this is done through /sys/devices/*/wakeup. I use the following
> script to enable wakeup when the remote is detected by udev:
>
> #!/bin/sh
> ################################################################################
> # wakeup_enable
> ################################################################################
>
> devpath=`readlink -f "/sys/${DEVPATH}"`
> while echo "${devpath}" | /bin/grep -q '^/sys/devices/' > /dev/null 2>&1
> ; do
> if test -e "${devpath}/power/wakeup" ; then
> state=`cat "${devpath}/power/wakeup"`
> if test "x${state}" = "xdisabled" ; then
> echo "enabled" > "${devpath}/power/wakeup"
> fi
> fi
> devpath=`dirname "${devpath}"`
> done
>
> exit 0
>
This didn't make it into last night's post here, but I did go looking
through /sys/devices/pci/pciXXXXX/power/wakeup and found that it did
indeed appear to be enabled. Adding to search terms a bit I found that
this has been discussed, with almost identical symptoms to mine, here:
http://comments.gmane.org/gmane.linux.usb.general/32115
Unfortunately I didn't find any resolution on the thread, and it was
some time back.
Leaves me wondering 2 things...
1 - How does your udev script know what device it's enabling wakeup for?
2 - The USB list seemed to suggest "fuller enablement". Do I need to go
into /sys/bus/usb/****/wakeup, as well? My mythbox is off/suspended and
the family watching TV at the moment, so it's not convenient to look.
They also talked about "kernel drivers" being involved. Don't the LIRC
drivers count on this?
I'm in a bit of a Catch-22 here. I can't move past 2.6.32 until I can
get the silly thing to wake-on-USB, and I can't go with in-kernel
drivers until I get past 2.6.32. Switching to in-kernel drivers calls
for rebuilding LIRC with different options, so it's no longer boot back
and forth, but boot+rebuild LIRC for any experimentation.
Dale Pontius
|
Thanks for helping keep SourceForge clean.
X