Hi,
Joerg Hoener wrote:
1.) Sometimes the initialization, returned one byte 0xFF. The remote works in
any case, but could it be that the initialization is not correct? What does
this return value states?
I did not look at this and I would not know what this would mean. Since
the remote seems to work in nevertheless, I assumed that the
initialization went ok.
2.) The remote distinguishes between 6 operating modes (for PC, TV, VCR, DVD,
SAT, AUX). In TV and AUX mode there is no data received by the radio adapter.
As far as I remember, this is right (I do not have the remote here for
testing).
For the rest of the modes, the codes and repetition is different.
Yes, and you can even change these codes by changing the vendor/model of
the controled TV/VCR/....
The PC mode
is the only one which sends data if the mouse emulation buttons are used. I
focused on PC mode because of this behaviour.
I saw the same and also decided (for the time being) only for this mode.
In PC mode there will always be
two commands of the same content received for one button press, regardless
how short a human could make it.
So I decided to record the repetition of every command (to make this more
clear: the repetition count is handled for every command seperately, I only
found one global repetition counter for the lola remote implementation), and
only discard the second command, this work well for me (The time between
commands is about 100 jiffies for my system (HZ being 1000), so I took a
value that is between 100 and 200 (HZ >> 3 actually), to detect if either a
repetition occured or the key was releasd meanwhile).
While testing I did not have problems with that (but I used a newer
version of the driver), but then my testing is not the usual thing you
do with it. I think it would be worth to implement this into the driver.
The only two keys which seemed to send 'key up' events were the two
mouse button keys.
4.) Another observation that I did not investigate further is that if you hold
down the left mouse button and also use the movement button, it will result
in much more movement of the mouse cursor.
That is very interesing. I will try it as soon as I can.
5.) I could also not reproduce the length values of 10 or 8 bytes that you
state in your post (the commands I received where 4 (for the mouse commands)
and 5 (for everything except the mouse commands) bytes in length). Maybe you
could go into more detail there.
I think I was wrong, they are 4 and 5 bytes, right.
I'm not a kernel driver developer, but adoption of the existing code was not
so difficult, so my offer is to assist you in development and of course do
some testing, but don't expect too much time that I can spend.
That is great. I assume we can do the negotiations by private email to
not spam the list.
to a) Sounds good, but be aware of the different modes, that can lead to more
code tables or a more complex code table.
Yes. I would nevertheless just concentrate on the PC mode and get that
working. After that, we might want to think about something more
sophisticated.
to c) Sounds good, but I can't think of such an highly configurable module
You are right with the key mappings. That might be better handled using
the event remapper. Things like being able to disable the remote mouse
would be nice I think.
So maybe we could combine the work that we have done on developing this
driver.
I would be very happy.
Frank
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
