Dear all,
a couple of weeks ago I decided to control my server, which plays
music using remote login anyway, using a RF remote control. I read
a lot about different models, mostly X10 or compatibles seemed to
be common and even supported by linux via lirc and, in newer
2.6 kernels, via the kernel module ati_remote.
So I got a "Qsonic Master Remote 6in1" from ebay. I assumed it would
be compatible to the usual X10. However, as you might guess, that is
not completely true, as turned out later.
It identifies itself as 0x0bc7:0x005. The remote is labeled UR86EL
and the USB receiver is labeled CM21A.
Now, lirc (in version 0.7.1) claims to
support this type. The problem was that I never got any reaction
to any keypress. I read that someone else had the problem that
the 'PC' key (which you use to activate the PC mode - the remote
can also be used for other devices) was programmed to some other
key. So I tried several 'reset' codes from the web, nothing worked.
Finally I stumbled over the note in some manual, that recarchable
batteries are not good, especially during the learning process
(and guess, I used such). Thus I went and bought usual alcali
batteries. Going through a couple of reset codes I finially found
one working (for the record: press SETUP (until LED goes on), STOP,
STOP, MUTE). I do not know if I tried this one before, so I do not
know if it was the code or the batteries that are responsible for
the success. I also did not care so much at that point. :)
How did I actually see, that it worked now? First, the mouse was
now activating the LED at the remote and, using the ati_remote kernel
module (kernel version 2.6.8 and patched to accept also the 0x005
product id) the pointer actually moved. Wow. But I also got a lot of
'Weird data' entries into my logs. However, I was happy at that point,
since firstly I was sure now that the device actually was not broken
and sencondly I realized that it should not be so hard to make it
working completely.
I was doing some debug and created a complete code table. However,
except the mouse buttons, all buttons have different codes than
the one in the recent ati_remote module (version 2.2.1 from kernel
version 2.6.11.10). It even has another format (10 bytes instead of 8,
completly other relation between the data).
So to me, that calls for another key table and another validation
function for this type of remote.
Now _you_ come into play. *hehe* Ich have a couple of questions before
I begin working on this more. (Meaning to provide a patch for this
remote)
1. Does anyone know if this already has been done by someone? I do not
want to spend my time on this just to dicover that I duplicted the
work of someone else. I searched the web for a really long time, but
found nothing.
2. Which version of ati_remote.c would be best for creating a patch
against it?
I found a number of patches on more than one mailing list which did
not seem to have entered the driver yet. (I am always speaking of
the one in the last stable kernel (2.6.11.10).
3. I know that some remotes can be switched to different channels. I
do not know how to do that with my remote, so I do not know how the
codes change if I change the channel (if the remote supports that
actually). Does someone know how to change the channel, even if
it is not exactly the same model?
I read about this once in some manual but could not find it again.
I could find out the different codes myself, I only need the way
to change the channel on the remote itself.
4. Do you think my work plan (below) is reasonable?
plan
----
At each point I would provide a patch to keep seperate things in
seperate patches, but since it is very likely that the patches overlap,
one thing would have to go after the other.
a) Include support for the new type with as less changes to the actual
code as possible
b) Convert some of the warn() to dbginfo() because I do not want to
have my logs filled with unknown codes someone else is sending.
This actually happened to me while testing.
c) Provide more options to the module to be able to configure the
remote more without having to recompile the module every time.
This includes:
b1) some special key <-> event mappings, which are questionable in
any way (example: KEY_PLAY <-> KEY_PLAYCD)
b2) maybe even a way to configure the whole table, but I have to
think about it more.
b3) option to disable the mouse part
b4) whatever comes to my (or your) mind later
d) Maybe tidy up the existing code table as well. It seems to me that
two numbers for each key are not needed. One number would do,
since theother one can always be computed from the first one.
(I would have to check that again and would have to have someone
testing that, because I do not have the hardware.)
Do not expect something after b) happening soon, as I am busy with
other things as well and it is not really needed to get me a working
remote control.
It would also be nice, if the maintainer of the module
(Torrey Hoffman?) could say something about it. :)
So, what do you think?
Last but not least I want to thank everybody who has put work into
this driver, I would not be able to write my own from scratch.
greetings, Frank
PS: I am on this list, you do not have to CC me.
-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
