lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <3e931de28d0091635547160680e17e5b.squirrel@intranet.cs.nmsu.edu>
Date:	Thu, 3 Sep 2009 08:35:54 -0600
From:	"Rick L. Vinyard, Jr." <rvinyard@...nmsu.edu>
To:	"Rick L. Vinyard, Jr." <rvinyard@...nmsu.edu>
Cc:	"Greg KH" <greg@...ah.com>,
	"Linux USB" <linux-usb@...r.kernel.org>,
	"LKML" <linux-kernel@...r.kernel.org>
Subject: Re: Problem starting the input interrupt pipe on the G13

Rick L. Vinyard, Jr. wrote:
> Greg KH wrote:
>> On Wed, Sep 02, 2009 at 03:25:50PM -0600, Rick L. Vinyard, Jr. wrote:
>>> Hello,
>>>
>>> I'm still working on the G13 driver, but I've run into a problem with
>>> the
>>> interrupt in pipe. In essence, I can't figure out how to get it
>>> started.
>>>
>>> The driver can be found at:
>>> http://g13.svn.sourceforge.net/viewvc/g13/driver/trunk/
>>>
>>> I think the root of the problem lies in the fact that the G13 usage
>>> page
>>> is 0x00 (undefined). The output and feature reports seem to be working
>>> fine to set the backlight color, the LCD image and the leds on the 'M'
>>> keys.
>>>
>>> However, nothing seems to be happening with the input report (there is
>>> only one input report type on endpoint address 0x81 that contains the
>>> joystick and key values).
>>>
>>> The problem is getting the input pipe started. I grepped through the
>>> other
>>> drivers in the hid directory and I couldn't find any that had to
>>> explicitly start the input interrupt.
>>
>> Have you just submitted an interrupt urb?
>>
>> That should be all that is needed, when the device has data, it will
>> return with it if your urb is pending.
>>
>
> I'll give it a shot.
>
> I hadn't tried it yet since I wasn't sure if that was the intended way to
> start it up within the HID framework since none of the other drivers
> submitted the urb.
>
> Also, submitting the urb requires the usbhid_device structure. Since the
> usbhid_device structure is defined in usbhid.h, and usbhid.h isn't
> installed with the kernel headers I wasn't sure if there was a better way
> to do it (raw events, input mapping or something along those lines).
>

Got it working. Submitting the URB didn't work because it wasn't open.
But, calling hdev->ll_driver->open(hdev) in probe opened it up and the
inputs are flowing now.

---

Rick


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ