Форум Beholder
http://beholder.ru/bb/

WinLIRC plugin for beholder
http://beholder.ru/bb/viewtopic.php?f=10&t=12396		 Страница 1 из 1
Автор:  dukeeeey [ 18 июл 2011, 00:37 ]
Заголовок сообщения:  WinLIRC plugin for beholder
Sorry for using english .. i don't speak any russian :) I found out from google that someone has made a beholder plugin for winlirc.
http://code.google.com/p/winlirc-beholder/

It works but only with 1 remote control, whatever remote control he is using. I've been studying the beholder remote api, and have concluded at least with the newer hardware it would probably be possible to support all NEC remotes which is quite nice.

I've written a skeleton plugin for winlirc based on this assumption, but I don't own a beholder receiver, I am not even sure you can buy them over here anyway. So I can't test/debug it to make sure it even works, which is a problem. Anyway if you guys are interested the plugin is here. Theres a compiled debug dll there.

http://sourceforge.net/projects/winlirc ... p/download

The best way to test is, is either with the RawCodes.exe that comes with winlirc. Raw codes shows the raw codes coming from the infra-red receiver. And if that works hopefully irrecord will work so configs can be generated.
Автор:  Admin [ 18 июл 2011, 11:19 ]
Заголовок сообщения:  Re: WinLIRC plugin for beholder
dukeeeey писал(а):
Sorry for using english .. i don't speak any russian :)

Not a problem.

dukeeeey писал(а):
I found out from google that someone has made a beholder plugin for winlirc.
http://code.google.com/p/winlirc-beholder/

It works but only with 1 remote control, whatever remote control he is using.

Let's clear out it a little. API is designed so, that it can be used both with many tuners and many (different) remote controls. For selecting tuner the function BTV_SelectCard is intended. For using multiple controls use function BTV_GetRCCodeEx from simplified C++ API.

dukeeeey писал(а):
I've been studying the beholder remote api, and have concluded at least with the newer hardware it would probably be possible to support all NEC remotes which is quite nice.

Actually most of our models support not only NEC remotes. The full list of currently supported standards is: NEC, JVC, Panasonic, Samsung, Sony SIRC-12, SIRC-15 and SIRC-20. This set allows to support about 80% of available remote controls on market.

dukeeeey писал(а):
I've written a skeleton plugin for winlirc based on this assumption, but I don't own a beholder receiver...

The best way to test is, is either with the RawCodes.exe that comes with winlirc. Raw codes shows the raw codes coming from the infra-red receiver. And if that works hopefully irrecord will work so configs can be generated.

Yes, it works :). And successfully show codes not only with our remote control but with foreign remotes also, for example with Creative RM-1500.
What can we do else to help you?
Please inform us when you change the status of plugin from debug to official.
Автор:  dukeeeey [ 18 июл 2011, 15:10 ]
Заголовок сообщения: 
Ãîëóáåâ, the author of
http://code.google.com/p/winlirc-beholder/

Helped me fix the issue that was stopping irrecord from working, which is great.

I've updated the link
http://sourceforge.net/projects/winlirc ... p/download
with the updated code, and a release build.

Just wants testing ! Try and generate some configs with irrecord, and see if you can find any problems.

The only bad thing about your API is the polling.

It would be better if it was something like this.

BOOL BTV_GetRCCodeEx (int timeout, ULONG *outCode);

Then we wouldn't have to rely on constantly asking if a code has been received. The timeout could be once a second so we could check if an exit event for my receive loop has been triggered. But otherwise its a nice API, the fact that you can support other remotes is great, this is what winlirc is all about !
Автор:  Admin [ 19 июл 2011, 11:01 ]
Заголовок сообщения: 
dukeeeey писал(а):
I've updated the link
http://sourceforge.net/projects/winlirc ... p/download
with the updated code, and a release build.

That's great!

dukeeeey писал(а):
The only bad thing about your API is the polling.

It would be better if it was something like this.

BOOL BTV_GetRCCodeEx (int timeout, ULONG *outCode);

The wrapper with timeout can be implemented fairly easy using the cycle with sleep function. We think that more useful may be the callback architecture with two events – key press and key release. But the problem is that this is far from physics of real process and may be very inaccurate.
Автор:  Orf [ 23 июл 2011, 14:24 ]
Заголовок сообщения: 
Admin писал(а):
We think that more useful may be the callback architecture with two events – key press and key release. But the problem is that this is far from physics of real process and may be very inaccurate.

Это надо понимать как если мы сами это реализуем с помощью отдельного потока для опросов и sleep'ов, у нас результаты будут лучше и он будет более точным ? :wink: все равно ведь там или здесь прийдется подбирать значение задержки между опросами. так что механизм с callback'ом очень бы хотелось увидеть в API. спрошу заодно, не планируется ли скомпилить BeholdRC.dll в x64 ? потому как счас в обоих каталогах на x64 системах устанавливается 32хбитная dll
Автор:  Admin [ 25 июл 2011, 10:46 ]
Заголовок сообщения: 
Нет, не так. Это значит, что механизм с коллбэком был бы, безусловно, красивей и удобней, но, к сожалению, физика процесса при работе с пультом сильно отличается от физики работы проводной клавиатуры. Поэтому такие коллбэки будут весьма криво работать.
А для чего нужна 64-битная DLL?
Автор:  Orf [ 25 июл 2011, 18:02 ]
Заголовок сообщения: 
Admin писал(а):
Нет, не так. Это значит, что механизм с коллбэком был бы, безусловно, красивей и удобней, но, к сожалению, физика процесса при работе с пультом сильно отличается от физики работы проводной клавиатуры.Поэтому такие коллбэки будут весьма криво работать.

Я примерно об этом и пытаюсь сказать. Но в результате мне самому ведь все равно приходится делать преобразование в события. Я сделал свою реализацию, но возможно ваша внутренняя реализация оказалась бы лучше :)

Admin писал(а):
А для чего нужна 64-битная DLL?

Из 64х битного процесса невозможно подгрузить 32х битную dll
Автор:  Admin [ 26 июл 2011, 10:06 ]
Заголовок сообщения: 
Orf писал(а):
Я сделал свою реализацию, но возможно ваша внутренняя реализация оказалась бы лучше :)

Весьма маловероятно.

Orf писал(а):
Из 64х битного процесса невозможно подгрузить 32х битную dll

Это мы в курсе. Я имел ввиду, есть ли какой-то конкретный софт, которому требуется 64-битная DLL?
Автор:  Orf [ 26 июл 2011, 15:01 ]
Заголовок сообщения: 
Admin писал(а):
Я имел ввиду, есть ли какой-то конкретный софт, которому требуется 64-битная DLL?

Есть софтинка, которую я использую для себя. Хотел потестировать, как она в 64битном виде будет выглядеть, и есть ли преимущества, пока уперся в вашу dllку
Страница 1 из 1 Часовой пояс: UTC + 3 часа