Version: (using KDE KDE 3.4.0) Installed from: SuSE RPMs OS: Linux I'm running SuSE 9.3/KDE 3.4 with a Hauppauge WinTV card and the original Hauppauge remote here. After setting up lirc 0.7.0 (needed to add bttv to /etc/sysconfig/kernel:MODULES_LOADED_ON_BOOT in order to successfully connect to the socket with irw via the ir-kbd-i2c kernel module and the input layer), it still shows kcmlirc::theMainLabel (There are no remotes ...) ;-) With sticking some fprintfs into the code, I tracked it down to IRKick::remotes returning (null), but haven't any idea for what reason this happens.. :-( It heavily smells like a timing problem, since sometimes (rarely) it works magically! Which uncovered the next problem: If it works, it's not possible to add any actions by pressing the key on the remote in kcmlirc "add action", and some keys, which are definitely defined in /etc/lircd.conf doesn't made it to the selection list: e.g. the "TV" key.., while the key list contains about 50 empty entries.. As you see, I'm not that helpless, but I'm not a C++/KDE coder (being a Qt-Pythoneer), but I can easily consume unified diffs, co cvs and the like.. I would love to get this going, thus I'm prepared to spend more time on this problem, just looking for advice, what to try next! Cheers, hp
I have fixed this bug in cvs HEAD. The problem was that kdelirc did not handle properly remotes having many buttons (about 200 or more), because all the buttons could not fit in the buffer of the socket and irkick is implemented so that when the buffer is empty it returns empty strings. That was the reason why you did get empty keys in the list. The reason that button presses were not accepted was that after irkick read the nulls it did not clear the input buffer, so when later you pressed the buttons those events were never read but instead remote key descriptions were read that were left in the buffer. The bug is now fixed in cvs but here is a workaround if you don't want to recompile: trim your /etc/lircd.conf to have fewer of buttons. A safe bet would be to have less than 100 buttons (which is not a problem because most of the buttons are not used from your /etc/lircd.conf). So this bug can be closed IMO, but unfortunately I don't have the rights to do it. I have even added BUGS:103668 to my cvs commit changelog, but it did not work because of permission problems.
Hi Zsolt, Am Sonntag, 17. April 2005 01:06 schrieb Zsolt Rizsanyi: > > ------- Additional Comments From rizsanyi users sourceforge net 2005-04-17 > 01:06 ------- I have fixed this bug in cvs HEAD. > The problem was that kdelirc did not handle properly remotes having many > buttons (about 200 or more), because all the buttons could not fit in the > buffer of the socket and irkick is implemented so that when the buffer is > empty it returns empty strings. That was the reason why you did get empty > keys in the list. > The reason that button presses were not accepted was that after irkick read > the nulls it did not clear the input buffer, so when later you pressed the > buttons those events were never read but instead remote key descriptions > were read that were left in the buffer. > > The bug is now fixed in cvs but here is a workaround if you don't want to > recompile: trim your /etc/lircd.conf to have fewer of buttons. A safe bet > would be to have less than 100 buttons (which is not a problem because most > of the buttons are not used from your /etc/lircd.conf). > > So this bug can be closed IMO, but unfortunately I don't have the rights to > do it. I have even added BUGS:103668 to my cvs commit changelog, but it did > not work because of permission problems. these are exceedingly good news. Unfortunately, I'm not that familiar with CVS to get to the patch. Do you know, how asking CVS to return a unified diff of your changes, relative to 3.4 release? In return, I will check them and let you know about the outcome (has to happen today, since I will leave tomorrow for 2 weeks. Thanks a lot, Pete
CVS commit by rizsanyi: Fix reading of remote data when it contains many buttons - above a certain limit the buttons did not fit into the socket buffer and the code only read till the buffer did not get empty Now it waits a short timeout and if new buttons arrive it continues reading. This is not the best solution to the problem, but it is satisfactory and the better ones would require code reorganization. BUGS:103668 M +13 -0 klircclient.cpp 1.7.2.1 --- kdeutils/kdelirc/irkick/klircclient.cpp #1.7:1.7.2.1 @@ -162,4 +162,17 @@ void KLircClient::slotRead() // <code> <name> QString btn = readLine(); + if (btn.isNull()) + { + // wait for 500 msecs to see if we receive more buttons + bool timeout; + theSocket->waitForMore(500, &timeout); + if (timeout) + { + // no more buttons break from the for loop + break; + } + btn = readLine(); + } + buttons.append(btn.mid(17)); }
I have backported the fix the the 3.3 and 3.4 branches, but if you still need a unified diff, then the next command should do it: cvs -d :pserver:anonymous@anoncvs.kde.org:/home/kde rdiff -u -r 1.9 -r HEAD kdeutils/kdelirc/irkick/klircclient.cpp
This is really great, but still doesn't solve the problems here for 100%. In fact, if I restart lircd, while irkick is running, it works fine, but that isn't the way, things are normally triggered, unfortunately :-(. Otherwise, the condition if(remotes.begin() == remotes.end()) is still met in KCMLirc::updateModes(), thus keeping it in unconfigurable state. I ran irkick for 10 times with the same result to backup my claim, but with restarting lircd, while irkick is running, it worked on the first try. Don't think this is a pure hazard. I've no idea, how to delay KCMLirc::updateModes() until the remotes are stable, most definitely caused by the many key definitions.. Atfer recompiling lircd with debug infos, it revealed a strange behavior of irkick always resetting twice in a row, which is (somewhat) visible also through the overlapping passive popups, announcing the several state changes.. It would be nice, if you find a way to cut the time needed to initialize that beast, while at it ;-) BTW, I've no idea, how to reopen this bug.
Ahh, forgot to login..
On Sunday 17 April 2005 15.57, Hans-Peter Jansen wrote: > ------- Additional Comments From hpj urpla net 2005-04-17 15:57 ------- > This is really great, but still doesn't solve the problems here for > 100%. In fact, if I restart lircd, while irkick is running, it works > fine, but that isn't the way, things are normally triggered, > unfortunately :-(. > Otherwise, the condition if(remotes.begin() == remotes.end()) > is still met in KCMLirc::updateModes(), thus keeping it in > unconfigurable state. I ran irkick for 10 times with the same result to > backup my claim, but with restarting lircd, while irkick is running, it > worked on the first try. Don't think this is a pure hazard. The strange thing is that it works for me. > I've no idea, how to delay KCMLirc::updateModes() until the remotes are > stable, most definitely caused by the many key definitions.. One way would be to connect updateModes to some signal that notifies when the remotes have been (re)read. You might ad a signal to IRKick class and emit that in IRKick::resetModes() and then hook the KCMLirc::updateModes to that signal. > Atfer recompiling lircd with debug infos, it revealed a strange behavior > of irkick always resetting twice in a row, which is (somewhat) visible > also through the overlapping passive popups, announcing the several > state changes.. It would be nice, if you find a way to cut the time > needed to initialize that beast, while at it ;-) I don't think that the problem is that it takes long to finish, but that there are more context changes while the loading and irkick is not prepared for those. But I hope the solution I proposed above would solve the issue. Since the problem is not appearing for me I cannot test this, but if you need it then I can write the code and send you the patch (altough the changes would be trivial). As for the double reset I don't know why is that happening, but it doesn't seem too harmfull :) I'm not sure if I understood all your issues correctly so please be patient with me :) Regards, Zsolt
>> Otherwise, the condition if(remotes.begin() == remotes.end()) >> is still met in KCMLirc::updateModes(), thus keeping it in >> unconfigurable state. I ran irkick for 10 times with the same result to >> backup my claim, but with restarting lircd, while irkick is running, it >> worked on the first try. Don't think this is a pure hazard. > The strange thing is that it works for me. Could it be, that your /etc/lircd.conf is smaller than mine? I've attached it for reference. >> I've no idea, how to delay KCMLirc::updateModes() until the remotes are >> stable, most definitely caused by the many key definitions.. > One way would be to connect updateModes to some signal that notifies when > the remotes have been (re)read. > You might ad a signal to IRKick class and emit that in IRKick::resetModes() > and then hook the KCMLirc::updateModes to that signal. The question is, how could the access to IRKick.remotes() delayed without significant changes to the whole infrastructure (at least in my poor C++ brain), but I must admit, that I don't overview the whole project at the moment... Apart from this, I will leave tomorrow for holiday, thus don't expect any proceedings from my side in the next two weeks. Thank you for your great involvment. It's heightly appreciated! Pete
Created attachment 10687 [details] My lircd.conf for reference Zsolt, could you do me a favor and try this one?
On Sunday 17 April 2005 20.52, Hans-Peter Jansen wrote: > ------- Additional Comments From hpj urpla net 2005-04-17 20:52 ------- > Created an attachment (id=10687) > --> (http://bugs.kde.org/attachment.cgi?id=10687&action=view) > My lircd.conf for reference > > Zsolt, could you do me a favor and try this one? zsolt@tm6000:~$ wc *.conf 364 728 11179 linux-input-layer-lircd.conf 364 728 11179 linux-input-layer-lircd-pete.conf 728 1456 22358 total It seems, that the number of buttons is the same. Altough there is difference: you have many buttons defined with the same code (0x10000). I found an updated one on Gerd Knorr's website and and the only change is that the 0x10000 codes are changed to new ones. But this change has no impact on kdelirc. Regards, Zsolt
Ahh, found it now, too and yes, there difference hasn't any impact on kdelirc. What version of lirc do you use? I'm on 0.7.0 here, and the SuSE patches are pretty minor. Other than that, I'm using the ir_kbd_i2c driver of a (typically heavy patched) 2.6.11.4 SuSE kernel with an athlon64 3k system and 1.5 GB RAM, running in i586 mode. Thus, I don't think, it's a matter of uncapable resources on my side.. ;) Mind telling me your config in order to figure out the diffs?
On Sunday 17 April 2005 22.52, Hans-Peter Jansen wrote: > Ahh, found it now, too and yes, there difference hasn't any impact on > kdelirc. What version of lirc do you use? I'm on 0.7.0 here, and the > SuSE patches are pretty minor. Lirc 0.7.0 on debian. > Other than that, I'm using the ir_kbd_i2c > driver of a (typically heavy patched) 2.6.11.4 SuSE kernel with an > athlon64 3k system and 1.5 GB RAM, running in i586 mode. Thus, I don't > think, it's a matter of uncapable resources on my side.. ;) Mine is athlon xp 2500+ with 0.5 GB RAM kernel: debian packaged 2.6.10 The only difference here might be in the kernel. Probably the threading model it uses could influence this, but I don't think it really matters. I have looked again at the source, and it seems my comment about connecting some signals and slots is completely false, because kcmlirc does not read directly the remote information from the socket, but leaves that to irkick and it request the remotes from irkick through dcop. So it seems that somehow irkick failed to get the remotes. Did you restart irkick after updating? If you want to debug anything you should debug irkick and not kcmlirc... Regards, Zsolt
> Mine is athlon xp 2500+ with 0.5 GB RAM > kernel: debian packaged 2.6.10 > The only difference here might be in the kernel. Probably the threading > model it uses could influence this, but I don't think it really matters. I don't think so either.. > I have looked again at the source, and it seems my comment about connecting > some signals and slots is completely false, because kcmlirc does not read > directly the remote information from the socket, but leaves that to irkick > and it request the remotes from irkick through dcop. > So it seems that somehow irkick failed to get the remotes. Did you restart > irkick after updating? Sure, it races somehow, because although the remote symbol isn't crossed and blinks on remote signals, kcmlirc doesn't detect the remotes, and I cannot see any way to protect access to that variable during transition states.. Also I have absolutely no idea about the dcop requirements of sync versus async behavior in this case: aka. what if we delay access to the remotes until they settled? Will stick some printfs into the offending areas on return from holiday. > If you want to debug anything you should debug irkick and not kcmlirc... Sure. Again, your sympathy is very helpful. Thanks && have a good night ;) Best regards, Pete
Is this still an issue or can this bug be closed?
it seems we can close it :D