-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Frank,
after also buying the Qsonic Master Remote 6in1 at pearl, searching for a driver the only thing I found was your post. It is btw. exactly the same as your model (same USB identification and labels). So what I did is get it working as fast as possible and I came over a few things that don't seem to be included within your last post. To complete the view I have to say that I started with the ati_remote driver from kernel version 2.6.4 (ati_remote verison 2.2.0), which has no support for the lola remote controller and there is no command repetition detection. As far as I could compare this version to the one included with kernel 2.6.9 (2.2.1) it seems that there is a repetition detection that discards up to 4-5 commands. During my initial development I recognized the following behaviour, for the Qsonic remote: 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? 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. For the rest of the modes, the codes and repetition is different. 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. 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. If you keep holding the button pressed the commands are repeated also. The time of the repetitions is 'always' the same, so you can't detect if the key is pressed just once or for a short while. Due to the same size of all time gaps between the commands I could not use the filter mechanism that was already implemented, because it filtered out every repetition with a certain amount of time between the next command, also discarding regular, wanted repetitions, that occur due to a longer button press. 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). 3.) I can't give you any new information on your point nr. 3.), because the situation is exactly the same for me. 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. 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. The follwing is what I noted on regarding the different modes(the 1 button is used as an example here): * 1 key analysis: * 1 press and release * * PC-Mode: * 20 ee 11 82 7d * 20 ee 11 82 7d * * TV: no radio signal emitted? * * VCR: * 20 5d d5 82 7d * 20 5d d5 82 7d * * DVD: * 20 c5 3a 99 66 * 20 f5 0a 85 7a * If the button is pressed for a longer period of time, both of the * messages are repeated, so it could not be taken as a indication for * key up and down. * * SAT: * 20 21 3c 40 bf * * AUX: no radio signal emitted? 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. With all this sayed I will give you my personal oppinion on your plan: to a) Sounds good, but be aware of the different modes, that can lead to more code tables or a more complex code table. to b) Your objection is ok although I think that it wouldn't matter in practice. to c) Sounds good, but I can't think of such an highly configurable module (which may use a config file for this purpose). Projects such as lirc may be the preferred way to go, but difficult to adopt to the existing scheme (I don't know how the connection to lirc is done, but it gives you the configurability that ony might need). to d) I can't see this atm but maybe there will be a more clear view on these issues in the future. So maybe we could combine the work that we have done on developing this driver. greetings, Jörg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFCo07XW+J45ls3rm4RAqRJAKCImzlK1mLbhW63KtEmzVvCGrYZRgCg1cLB Onq/Bl/dRRS2GdxqlLqUV6M= =oXGK -----END PGP SIGNATURE----- ------------------------------------------------------- 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 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
