EventGhost

Hello!

This is the Lirc Client plugin support thread, post any questions, comments, suggestions, bug reports etc. about this plugin in this thread. As always feedback from users would be very welcome!

I have posted a guide explaining how to run winlirc with realtime priority, which improves it's performance, in this post.

As of December 2007 you can find the latest version of these files in the EventGhost SVN. They are also included in all future beta versions, so easiest way to obtain the latest version is to install the latest nightly beta.

I have quoted the original starting post for the thread below, since it's become quite irrelevant as a starting post.


Plugin Developer,
-jinxdone

Very nice work. I currently can't try it out, because I disassembled my Lirc receiver.


No, and it shouldn't disable itself. But you can raise an exception inside your __start__ method to indicate your plugin didn't started up correctly. EG will then show your plugin in red. Just write:

But EG will regardless of that call your __stop__/__close__ methods, so you have to take care that they don't depend on something that should have done successful in the __start__ method.


You can use eg.RawReceiverPlugin instead of eg.PluginClass. RawReceiverPlugin has an internal repeat supression, that users can fine tune. This tuning has to be done with a Python script currently, but this might enhance in the future.
http://www.eventghost.org/forum/viewtopic.php?t=34


They are not "disallowed", the forum software simply has no function for them. It would need an addon and such addons make updating the forum software complicated. But we will find a way for uploads some day.

I must correct myself. This is not true. Once the plugin has raised eg.Exception, it will not get a __stop__ call. But it might get a __close__ call.

Hi jinxdone,

nice job. I discovered eventghost several weeks back, and your plug'in decided me to build a lirc receiver. Your plugin works for me. Thank folks ! Realy impressive job !

But I try to control the mouse move with my remote, but their is no acceleration at all. The repeat work, but the individual step of the mouse is so small that not usable. If I keep the remote button pressed, the mouse move on my screen, but really slowly ....
For you info, i run winlirc in realtime with the command line you suggest.

Do you think the eg.RawReceiverPlugin suggested by bitmonster could solve this issue ? Do I just need to replace eg.PluginClass by eg.RawReceiverPlugin in __init__.py ?

If you have an other version, I could help you to test it and give you feedback

Regards,
Nico

Do you get multiple events while holding down a single button?

Bitmonster, yes I have multiple event with the original __init__.py

But, I just replace eg.PluginClass by eg.RawReceiverPlugin in this script, line 149:

replace by:


And It works ! The mouse is now accelerated when I keep the button pressed on the remote.

Regards

Hello again!

I just updated the plugin a little bit, I removed some obsolete code and switched over to using the RawReceiverPlugin class. And now you can also adjust the enduring event timeout. Sorry it took so long to do anything about it but I have been quite busy.. (oh the excuses )

Still though, I don't think it's possible to raise that exception from inside the __start__ method, as asyncore forks into background and after a certain time it calls the handle_expt() if it fails..


I'd be happy to hear any feedback you guys might have on it..

Take care!

I have included your plugin in the 0.3.6.1049 beta version.

You are right that eg.Exception won't work right if called from another thread (like asyncore). I will have to think about a way how you can put your plugin into the error state in such situations.

@jinxdone
I've made some changes to EG's exception handling and your plugin code in 0.3.6.1055.

I changed your handle_expt this way:

First I directly close the reader and set the plugin's reader variable to None, so no further request should throw an exception. Now comes the complicated part. We cannot directly raise an exception inside asyncore.dispatcher, because we have no control over the asyncore thread. We need to direct it to the thread the plugin is running in and that is eg.actionThread. The "Call" method of this thread will execute the supplied callable (self.handler.HandleException) with the supplied arguments (the message text) in its own thread.

So after this the plugin's HandleException is executed and I have defined it this way:

So here we simply raise the exception with the message. Now EG will print the msg and set your plugin into error state (indicated through a red label). If the user re-configures your plugin, the whole process starts over and it might succeed or the plugin will again go into error state.

Very good.. I suppose you did the neccessary changes in eventghost to make raising the exception outside the __start__ method possible.


Is it possible to have actions in the same plugin?
I was going to add support for sending strings to the lirc-server as well (for transmitting IR codes), but that idea got shot down since it seems like it's not possible to have actions with RawReceiverPlugin class for the time being.

But that's not a very high priority obiviously, as you can just use the included Network Sender plugin for that same functionality.

RawReceiverPlugin works fine with actions. The USB-UIRT, Serial and Tira plugins use it.


I don't think the Network Sender plugin will work with LIRC. It uses another protocol.

I've just integrated a small modification into your code, because I had to change the way the asyncore.loop is handled. Formerly I used a thread that runs asyncore.loop with a dummy socket, so this loop is available to all code that uses asyncore.dispatcher or asynchat. The problem is, that the asyncore.loop uses select() to handle updates on the sockets. While select() is waiting for a change on the sockets, it will not take newly added sockets into account. So I used a rather small timeout (one second), after which select() should end and update its socket list.

Now I have removed this timeout and to inform asyncore.loop of a new socket, one has to call "eg.RestartAsyncore()" after creation of a new socket. This function will close the dummy socket, which will awake select(), and then creates a new dummy socket for the next call. This way EG uses less regular computation and new sockets are available immediately. I've changed all plugins relying upon asyncore accordingly (Zoom Player, VLC, Network Receiver).

Hi,

There is a plugin for ati remote wonder called winlirc_rw, wich sends winlirc comands for winlirc compatible software (the reverse action of you current plugin). I was thinking that it should not be very hard for you to do this if you want. This way alot of software not yet suported by eventghost would work with it (alot of dvb-s world use dvbdream, wich only support winlirc).

Thank you.

ps. i also have winlirc_rw source_code if you need it (cpp)

Hello again! Time for an update!

I just posted v0.7.0 as an attachment to the first of the thread post.



I also changed the name to "Lirc Client", as it now both receives and sends events.

If somebody can test the new functionality I'd be very happy to hear some feedback as I don't have a Lirc-server set up right now that could send IR codes.. At least winlirc v0.65 spews errors at me when trying to send events, but I suspect that might be a lack of or broken functionality on winlirc's part. It'd be superb if somebody could test it with a *nix version of Lirc.

Of course any comments and feedback is very welcome!


It's possible there are bugs in there, but I'll fix those for 0.7.x. I've stared at the code enough for today!
It needs a bit of cleanup anyway so I'll get to it sometime in the near future.


*oh, and townkat, if i'll do that lirc-server-feature i think it'll be another plugin alltogether.. but i'll keep it in mind

please also atach the file, you made me curious

and of corse the lircserver needs to be a diffrent plugin