Re: [vdr] [ANNOUNCE] improved LIRC remote for VDR-1.5.12
On 02/09/08 13:53, Anssi Hannula wrote: > Klaus Schmidinger wrote: >> On 01/09/08 00:44, Reinhard Nissl wrote: #vdr REMOTE=LIRC LIRC_PUSHFREQ=64 # 1/s LIRC_REPEATDELAY=250 # ms LIRC_REPEATFREQ=32 # 1/s #LIRC_REPEATTIMEOUT=500 # ms #LIRC_RECONNECTDELAY=3000 # ms LIRC_PRIORITYBOOST=1 >> Isn't there a way to have all this done in LIRC itself? >> I can hardly imagine that all other applications using LIRC do >> such elaborate parameter fiddling, too. > > I think most other applications use the lirc library instead of directly > parsing the commands. Then maybe that would be a good idea for VDR, too? Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] improved LIRC remote for VDR-1.5.12
Klaus Schmidinger wrote: > On 01/09/08 00:44, Reinhard Nissl wrote: >>> #vdr >>> REMOTE=LIRC >>> LIRC_PUSHFREQ=64 # 1/s >>> LIRC_REPEATDELAY=250 # ms >>> LIRC_REPEATFREQ=32 # 1/s >>> #LIRC_REPEATTIMEOUT=500 # ms >>> #LIRC_RECONNECTDELAY=3000 # ms >>> LIRC_PRIORITYBOOST=1 > > Isn't there a way to have all this done in LIRC itself? > I can hardly imagine that all other applications using LIRC do > such elaborate parameter fiddling, too. I think most other applications use the lirc library instead of directly parsing the commands. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] improved LIRC remote for VDR-1.5.12
On 01/09/08 00:44, Reinhard Nissl wrote: > Hi, > > I was quite annoyed how I could operate my EPIA MII-6000E using a > LIRC remote. It was almost not possible to navigate through the > OSD in a fast way. > > The attached patch allows now to define timeouts and frequencies > for example in Make.config, so there is no need to patch every > VDR version. Furthermore, frequencies are now defined in unit 1/s > instead of the unit ms (which defined the period), making values > more intuitive. > > There's now an additional frequency which defines, how fast a > user is allowed to press the same button repeatedly. The > originally used REPEATDELAY allowed only 2.85 button presses per > second. > > On slow and busy machines like my EPIA it happened often that > several button presses were read by VDR in a single read, but > only the first one got processed. The code now reads only a > single button press from LIRC's socket, so button presses don't > get lost (although presses of the same button will be skipped as > the timeouts don't get reached). > > To make it less likely that button presses get processed in > chunks a further define allows to decrease the thread's niceness > which means to boost it's priority. This feature requires VDR to > be run as root. > > This is my setup which follows some common settings found in > mainboard bioses for keyboard repeat delay and frequency. > >> #vdr >> REMOTE=LIRC >> LIRC_PUSHFREQ=64 # 1/s >> LIRC_REPEATDELAY=250 # ms >> LIRC_REPEATFREQ=32 # 1/s >> #LIRC_REPEATTIMEOUT=500 # ms >> #LIRC_RECONNECTDELAY=3000 # ms >> LIRC_PRIORITYBOOST=1 Isn't there a way to have all this done in LIRC itself? I can hardly imagine that all other applications using LIRC do such elaborate parameter fiddling, too. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] improved LIRC remote for VDR-1.5.12
On Saturday 12 January 2008, Reinhard Nissl wrote: > Ville Skyttä schrieb: > > > Also, somewhat off topic: when running powertop[1] on my VDR box, I see > > lircd waking up the CPU from idle about 1000 times a second while VDR is > > connected to it: > > > > Top causes for wakeups: > > 54.3% (988.1) lircd : schedule_timeout (process_timeout) > > 28.5% (518.4) vdr : futex_wait (hrtimer_wakeup) > > [...] > > > > I already tried adding some cCondWait::SleepMs's to VDR's lirc action > > loop but it didn't seem to have any effect. Any ideas whether this is > > something that VDR could do anything about, or if it's a LIRC internal > > thing? > > Well VDR's lirc action loop uses a timeout only when it needs to > generate a keyup event after a key repeat event. Otherwise it > blocks in cFile::FileReady's select() until a button gets pressed > on the remote. > > Try running irw instead of VDR and check powertop again. Yep, same thing with irw so I suppose this needs to be addressed in LIRC, not VDR. Thanks. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] improved LIRC remote for VDR-1.5.12
Hi, Ville Skyttä schrieb: >> I think, the LIRC protocol misses a timestamp for each button >> press. Or an even more favorable solution would be to put the >> timeout and frequency processing into LIRC and have VDR to >> process each key as it arrives, just like with the KBD remote. > > Would using liblirc_client instead of the current "homebrew" implementation > help out with this? When liblirc_client uses the same interface of lircd, then I don't think that it will help. > Also, somewhat off topic: when running powertop[1] on my VDR box, I see lircd > waking up the CPU from idle about 1000 times a second while VDR is connected > to it: > > Top causes for wakeups: > 54.3% (988.1) lircd : schedule_timeout (process_timeout) > 28.5% (518.4) vdr : futex_wait (hrtimer_wakeup) > [...] > > I already tried adding some cCondWait::SleepMs's to VDR's lirc action loop > but > it didn't seem to have any effect. Any ideas whether this is something that > VDR could do anything about, or if it's a LIRC internal thing? Well VDR's lirc action loop uses a timeout only when it needs to generate a keyup event after a key repeat event. Otherwise it blocks in cFile::FileReady's select() until a button gets pressed on the remote. Try running irw instead of VDR and check powertop again. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] improved LIRC remote for VDR-1.5.12
On Saturday 12 January 2008, Reinhard Nissl wrote: > I think, the LIRC protocol misses a timestamp for each button > press. Or an even more favorable solution would be to put the > timeout and frequency processing into LIRC and have VDR to > process each key as it arrives, just like with the KBD remote. Would using liblirc_client instead of the current "homebrew" implementation help out with this? Also, somewhat off topic: when running powertop[1] on my VDR box, I see lircd waking up the CPU from idle about 1000 times a second while VDR is connected to it: Top causes for wakeups: 54.3% (988.1) lircd : schedule_timeout (process_timeout) 28.5% (518.4) vdr : futex_wait (hrtimer_wakeup) [...] I already tried adding some cCondWait::SleepMs's to VDR's lirc action loop but it didn't seem to have any effect. Any ideas whether this is something that VDR could do anything about, or if it's a LIRC internal thing? [1] http://www.lesswatts.org/projects/powertop/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] improved LIRC remote for VDR-1.5.12
Hi, Ludwig Nussel schrieb: > Since the lirc thread doesn't do anything except waiting for input > most of the time it should be scheduled quickly anyways. Maybe the > useless select timeout destroys that advantage somewhat. I don't think so. In my case (i. e. on my EPIA MII-6000E), there are a lot of other threads from xine-lib for example which cause already noticeable load and due to the xine-lib design, boost their priority a bit on their own (e. g. the video out thread). > Also if multiple lines in the buffer are a problem what about > changing the code to consume only one line at a time instead of > messing with thread priorities? The patch addresses this issue already. But VDR processes these button presses with almost no delay so they will be dropped. I think, the LIRC protocol misses a timestamp for each button press. Or an even more favorable solution would be to put the timeout and frequency processing into LIRC and have VDR to process each key as it arrives, just like with the KBD remote. I've first tried to process each key as it arrives but the result wasn't useable as the remote used a too short repeat delay. So most often, one moved on for two items instead of one (per button press). Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] improved LIRC remote for VDR-1.5.12
Hi, Nicolas Huillard schrieb: > An option would be to lower priority of all threads except this one. I > guess only relative priority within VDR is important. > You can also raise priority in your init scripts (nice=-N), before > running VDR. This way every thread will have nice=0 priority, except the > LIRC one, which will stay at nice=-N That doesn't work as there is no collection of threads in VDR which would be necessary to catch all threads for example which are created by plugins. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] improved LIRC remote for VDR-1.5.12
Reinhard Nissl wrote: > The attached patch allows now to define timeouts and frequencies > for example in Make.config, so there is no need to patch every > VDR version. Furthermore, frequencies are now defined in unit 1/s > instead of the unit ms (which defined the period), making values > more intuitive. > I would prefer some OSD settings for LIRC (if possible) because on every VDR setup you are able to do first controls with the keyboard. So you could access the settings menu and tune the LIRC settings the way you want. A makefile settings also will not work if you use some prebuild packages. I also remember the time using LIRC when I always had to patch the lirc code - currently, I am glad being able to use DVB-IR. :) With kind regards Jörg ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] improved LIRC remote for VDR-1.5.12
Nicolas Huillard wrote: > Reinhard Nissl a écrit : > > Dominique Matz schrieb: > > > >> sound very good, but vdr as root do not :-( > >> > >> do you think it is possible to use this or something else with an non > >> root user? > > > > Well, only the LIRC_PRIORITYBOOST option requires root privileges > > to work. If you don't have root privileges, you'll just get an > > error logged and the LIRC thread runs without any change in > > priority -- that's all. See man setpriority for details. > > An option would be to lower priority of all threads except this one. I > guess only relative priority within VDR is important. > You can also raise priority in your init scripts (nice=-N), before > running VDR. This way every thread will have nice=0 priority, except the > LIRC one, which will stay at nice=-N Since the lirc thread doesn't do anything except waiting for input most of the time it should be scheduled quickly anyways. Maybe the useless select timeout destroys that advantage somewhat. Also if multiple lines in the buffer are a problem what about changing the code to consume only one line at a time instead of messing with thread priorities? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] improved LIRC remote for VDR-1.5.12
Reinhard Nissl a écrit : > Dominique Matz schrieb: > >> sound very good, but vdr as root do not :-( >> >> do you think it is possible to use this or something else with an non >> root user? > > Well, only the LIRC_PRIORITYBOOST option requires root privileges > to work. If you don't have root privileges, you'll just get an > error logged and the LIRC thread runs without any change in > priority -- that's all. See man setpriority for details. An option would be to lower priority of all threads except this one. I guess only relative priority within VDR is important. You can also raise priority in your init scripts (nice=-N), before running VDR. This way every thread will have nice=0 priority, except the LIRC one, which will stay at nice=-N -- NH ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] improved LIRC remote for VDR-1.5.12
Hi, Dominique Matz schrieb: > sound very good, but vdr as root do not :-( > > do you think it is possible to use this or something else with an non > root user? Well, only the LIRC_PRIORITYBOOST option requires root privileges to work. If you don't have root privileges, you'll just get an error logged and the LIRC thread runs without any change in priority -- that's all. See man setpriority for details. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] improved LIRC remote for VDR-1.5.12
Hi Reinhard, sound very good, but vdr as root do not :-( do you think it is possible to use this or something else with an non root user? I think many use vdr with an special non root user, for example all which use gentoo. greetings mentox aka dominique Reinhard Nissl schrieb: > Hi, > > I was quite annoyed how I could operate my EPIA MII-6000E using a > LIRC remote. It was almost not possible to navigate through the > OSD in a fast way. > > The attached patch allows now to define timeouts and frequencies > for example in Make.config, so there is no need to patch every > VDR version. Furthermore, frequencies are now defined in unit 1/s > instead of the unit ms (which defined the period), making values > more intuitive. > > There's now an additional frequency which defines, how fast a > user is allowed to press the same button repeatedly. The > originally used REPEATDELAY allowed only 2.85 button presses per > second. > > On slow and busy machines like my EPIA it happened often that > several button presses were read by VDR in a single read, but > only the first one got processed. The code now reads only a > single button press from LIRC's socket, so button presses don't > get lost (although presses of the same button will be skipped as > the timeouts don't get reached). > > To make it less likely that button presses get processed in > chunks a further define allows to decrease the thread's niceness > which means to boost it's priority. This feature requires VDR to > be run as root. > > This is my setup which follows some common settings found in > mainboard bioses for keyboard repeat delay and frequency. > > >> #vdr >> REMOTE=LIRC >> LIRC_PUSHFREQ=64 # 1/s >> LIRC_REPEATDELAY=250 # ms >> LIRC_REPEATFREQ=32 # 1/s >> #LIRC_REPEATTIMEOUT=500 # ms >> #LIRC_RECONNECTDELAY=3000 # ms >> LIRC_PRIORITYBOOST=1 >> > > Bye. > > > > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] improved LIRC remote for VDR-1.5.12
Hi,
I was quite annoyed how I could operate my EPIA MII-6000E using a
LIRC remote. It was almost not possible to navigate through the
OSD in a fast way.
The attached patch allows now to define timeouts and frequencies
for example in Make.config, so there is no need to patch every
VDR version. Furthermore, frequencies are now defined in unit 1/s
instead of the unit ms (which defined the period), making values
more intuitive.
There's now an additional frequency which defines, how fast a
user is allowed to press the same button repeatedly. The
originally used REPEATDELAY allowed only 2.85 button presses per
second.
On slow and busy machines like my EPIA it happened often that
several button presses were read by VDR in a single read, but
only the first one got processed. The code now reads only a
single button press from LIRC's socket, so button presses don't
get lost (although presses of the same button will be skipped as
the timeouts don't get reached).
To make it less likely that button presses get processed in
chunks a further define allows to decrease the thread's niceness
which means to boost it's priority. This feature requires VDR to
be run as root.
This is my setup which follows some common settings found in
mainboard bioses for keyboard repeat delay and frequency.
> #vdr
> REMOTE=LIRC
> LIRC_PUSHFREQ=64 # 1/s
> LIRC_REPEATDELAY=250 # ms
> LIRC_REPEATFREQ=32 # 1/s
> #LIRC_REPEATTIMEOUT=500 # ms
> #LIRC_RECONNECTDELAY=3000 # ms
> LIRC_PRIORITYBOOST=1
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
--- ../vdr-1.5.12-dvbs2-other/lirc.c 2006-05-28 10:48:13.0 +0200
+++ lirc.c 2008-01-08 22:28:38.0 +0100
@@ -13,10 +13,24 @@
#include
#include
-#define REPEATDELAY 350 // ms
-#define REPEATFREQ 100 // ms
-#define REPEATTIMEOUT 500 // ms
-#define RECONNECTDELAY 3000 // ms
+#ifndef LIRC_PUSHFREQ
+#define LIRC_PUSHFREQ 3 // 1/s
+#endif
+#ifndef LIRC_REPEATDELAY
+#define LIRC_REPEATDELAY 350 // ms
+#endif
+#ifndef LIRC_REPEATFREQ
+#define LIRC_REPEATFREQ 10 // 1/s
+#endif
+#ifndef LIRC_REPEATTIMEOUT
+#define LIRC_REPEATTIMEOUT 500 // ms
+#endif
+#ifndef LIRC_RECONNECTDELAY
+#define LIRC_RECONNECTDELAY 3000 // ms
+#endif
+#ifndef LIRC_PRIORITYBOOST
+#define LIRC_PRIORITYBOOST 0
+#endif
cLircRemote::cLircRemote(const char *DeviceName)
:cRemote("LIRC")
@@ -68,17 +82,33 @@ void cLircRemote::Action(void)
bool repeat = false;
int timeout = -1;
+ if (LIRC_PRIORITYBOOST)
+ SetPriority(GetPriority() - LIRC_PRIORITYBOOST);
while (Running() && f >= 0) {
-
bool ready = cFile::FileReady(f, timeout);
-int ret = ready ? safe_read(f, buf, sizeof(buf)) : -1;
+int ret = -1;
+if (ready) {
+ // read one line of the line oriented lirc protocol
+ for (ret = 0; ret < (int)sizeof(buf); ret++) {
+ int ch = readchar(f);
+ if (ch < 0) {
+ ret = -1;
+ break;
+ }
+ if (ch == '\n') {
+ buf[ret++] = '\0';
+ break;
+ }
+ buf[ret] = ch;
+ }
+ }
if (ready && ret <= 0 ) {
- esyslog("ERROR: lircd connection broken, trying to reconnect every %.1f seconds", float(RECONNECTDELAY) / 1000);
+ esyslog("ERROR: lircd connection broken, trying to reconnect every %.1f seconds", float(LIRC_RECONNECTDELAY) / 1000);
close(f);
f = -1;
while (Running() && f < 0) {
- cCondWait::SleepMs(RECONNECTDELAY);
+ cCondWait::SleepMs(LIRC_RECONNECTDELAY);
if (Connect()) {
isyslog("reconnected to lircd");
break;
@@ -94,7 +124,7 @@ void cLircRemote::Action(void)
continue;
}
if (count == 0) {
- if (strcmp(KeyName, LastKeyName) == 0 && FirstTime.Elapsed() < REPEATDELAY)
+ if (strcmp(KeyName, LastKeyName) == 0 && FirstTime.Elapsed() < (1000 / LIRC_PUSHFREQ))
continue; // skip keys coming in too fast
if (repeat)
Put(LastKeyName, false, true);
@@ -104,18 +134,18 @@ void cLircRemote::Action(void)
timeout = -1;
}
else {
- if (LastTime.Elapsed() < REPEATFREQ)
+ if (LastTime.Elapsed() < (1000 / LIRC_REPEATFREQ))
continue; // repeat function kicks in after a short delay (after last key instead of first key)
- if (FirstTime.Elapsed() < REPEATDELAY)
+ if (FirstTime.Elapsed() < LIRC_REPEATDELAY)
continue; // skip keys coming in too fast (for count != 0 as well)
repeat = true;
- timeout = REPEATDELAY;
+ timeout = LIRC_REPEATDELAY;
}
LastTime.Set();
Put(KeyName, repeat);
}
else if (repeat) { //
