Dear Jiri,

Sorry for the late reply. I did not have access to my remote control, because I 
was home during the weekend.

Yesterday evening I was able to play with my remote control again and I'd
like to share a small success story with you.

In drivers/input/input.c in input_event I found following code

if(dev->sync)
        return;
dev->sync=1

So I just received just the very first event. After that the function
returns prematurely and NEVER gets to the COMMON event call at the body
of the function. 

After commenting those code and compiling again, I really got a EVENT for
EVERY keystroke :) I was very hapy about that.

DEFINTELY this is NOT the correct way to proceed. Something should set
sync to 0 sometimes and the above code shall stay intact, instead.
But I do not know where. do you

---------------

Beeing happy about getting every event I have a small c program to read
one event structure(16 bytes)  each and to display it.
It turned out as time=correct type=(random number up to 100000) code=0 value=0
There are even different types for same keystrokes

-------------

You told me to send you all that debug information.
It was not so easy for me, because I was only able to activate debug by 
uncommenting #ifdef DEBUG lines. and printing /proc/kmsg .I do NOT know, how to 
change the linux but I still got some debug

report (size=4) unnumbered
report 0(size=4) 40 00 19 0f

This also corresponds to the usbmon findings.

The bytes sent from the receivers are as follows:


40 00 <keycode> 0f - keypress
40 80 <keycode> 0f - keyrelease

This is valid for most keys, but there are others starting with 88,89 
but the message is ALWAYS 4 bytes.

Maybe you can tell me:


* How can I correctly resolve the SYNC issue ?
* How can I correctly get the information into my userlevel c program ?

rds


-------- Original-Nachricht --------
Datum: Fri, 23 Feb 2007 14:37:14 +0100 (CET)
Von: Jiri Kosina <[EMAIL PROTECTED]>
An: Guenther Sohler <[EMAIL PROTECTED]>
CC: linux-usb-devel@lists.sourceforge.net, Dmitry Torokhov <[EMAIL PROTECTED]>
Betreff: Re: [linux-usb-devel] Still Problems with USB Remote control

> On Fri, 23 Feb 2007, Guenther Sohler wrote:
> 
> > Some weeks before I have already reported about problems with my USB 
> > Remote control which I obtained from eBay. I got a remote control sender
> > and a IR receiver with an USB cable, which I plug into my computer. I 
> > expect receiving the events through /dev/input/event7 but it does not 
> > work out.
> > The only chance to receive an event is
> > * i plug in the receiver
> > * i press a button on the remote control
> > * i cat /dev/input/event7
> > Starting on that i cannot receive more events unless i unplug the cable 
> > and plug it again.
> > drivers/usb/input/hid-core.c: hid_irq_in
> > drivers/hid/hid-input.c: hid_input_report
> > include/linux/input.h: input_sync
> > drivers/input/input.c:input_event
> > <======== BROKEN PIPE =========>
> > drivers/input/evdev.c:evdev_event
> > evdev->wait waitqueue
> > drivers/input/evdev.c:evdev.c
> 
> Hi Guenter,
> 
> what does the "BROKEN PIPE" sign exactly mean here? Does the cat 
> /dev/input/event7 get -EPIPE error, or does it mean anything else?
> 
> Also, could you please be more specific what kind of remote control 
> (vendor/product) is that?
> 
> > At the denoted place <======Broken Pipe ==> In the function input_event 
> > with the configuration sent from input_sync it will NOT call the event 
> > function from evdev. Thus it does not know that new data is available. 
> > Maybe hid_input_report should call another function but input_sync 
> > instead ...
> 
> Sorry, I don't fully understand this paragraph, could you be please more 
> specific?
> 
> Could you please also try to build hid and usbhid in debugging mode, so 
> that we could see better what is happening (though from your description 
> of the problem it is not clear to me whether the problem is in hid-input 
> or input)? If you are using 2.6.21-rc1, this could be accomplished by 
> setting HID debug in kernel configuration menu.
> 
> If you are using older kernel, you'd have to define DEBUG and DBEUG_DATA 
> macros in drivers/hid/hid-core.c, drivers/hid/hid-input.c and 
> drivers/usb/input/hid-core.c
> 
> > Maybe somebody can point me out a better mailing list to ask, because my
> > problem is not only USB related, but expands about usb, input driver, 
> > HID driver. Looking at the output of usbmon, the usb part actuallyt 
> > seems to work quite fine. The Only problem seems the transmission of the
> > events to /dev/input/event7
> 
> I added Dmitry to CC.
> 
> -- 
> Jiri Kosina

-- 
"Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ...
Jetzt GMX ProMail testen: www.gmx.net/de/go/mailfooter/promail-out

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to