Hi Alan
2017-09-21 0:50 GMT+09:00 Alan Stern :
> On Wed, 20 Sep 2017, Kim Jaejoong wrote:
>
>> To. usb & input guys.
>>
>> While dig this report, i was wondering about bNumDescriptors in HID
>> descriptor.
>> HID document from usb.org said, 'this number must be at least one (1)
>> as a Report des
On Wed, 20 Sep 2017, Kim Jaejoong wrote:
> To. usb & input guys.
>
> While dig this report, i was wondering about bNumDescriptors in HID
> descriptor.
> HID document from usb.org said, 'this number must be at least one (1)
> as a Report descriptor will always be present.'
>
> There is no mentio
On Wed, Sep 20, 2017 at 6:57 AM, Kim Jaejoong wrote:
> Hi Andrey
>
> 2017-09-19 21:38 GMT+09:00 Andrey Konovalov :
>> Hi Kim,
>>
>> I'm not sure. Is there a check on the bLength field of a
>> hid_descriptor struct? Can it be less than sizeof(struct
>> hid_descriptor)? If so, we still do an out-of-
Hi Andrey
2017-09-19 21:38 GMT+09:00 Andrey Konovalov :
> On Tue, Sep 19, 2017 at 1:47 PM, Kim Jaejoong wrote:
>> Hi, Andrey Konovalov
>>
>> Thanks for the report.
>>
>> 2017-09-19 2:33 GMT+09:00 Andrey Konovalov :
>>> Hi!
>>>
>>> I've got the following crash while fuzzing the kernel with syzkall
On Tue, Sep 19, 2017 at 1:47 PM, Kim Jaejoong wrote:
> Hi, Andrey Konovalov
>
> Thanks for the report.
>
> 2017-09-19 2:33 GMT+09:00 Andrey Konovalov :
>> Hi!
>>
>> I've got the following crash while fuzzing the kernel with syzkaller.
>>
>> On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 1
Hi, Andrey Konovalov
Thanks for the report.
2017-09-19 2:33 GMT+09:00 Andrey Konovalov :
> Hi!
>
> I've got the following crash while fuzzing the kernel with syzkaller.
>
> On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18).
>
> It seems that there's no proper check on the hdesc->bNumDes
Hi!
I've got the following crash while fuzzing the kernel with syzkaller.
On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18).
It seems that there's no proper check on the hdesc->bNumDescriptors
value in usbhid_parse(). it iterates over hdesc->desc and accesses
hdesc->desc[n] fields, whi
Am Montag, den 19.06.2017, 18:18 + schrieb Abdulhadi Mohamed:
> Note that my device exposes configurations with a bInterfaceSubclass of
> 1(Boot Interface) as required.
Only those or those in addition to other configurations?
Which configuration is chosen?
Regards
Oli
Hello,
I have been trying to get my composite HID gadget to work in BIOS via the Boot
Protocol. However, I've noticed that the set_protocol() command to switch the
device to boot mode from report mode is not implemented in the hidg_setup
function in the HID function driver (f_hid.c). How hard
Am Dienstag, den 06.06.2017, 12:30 + schrieb Abdulhadi Mohamed:
> Hi
>
> I apologize in advance for this is my first email using this mailing list but
> I could really use some help. I have connected a composite USB device running
> the 4.0 Linux kernel to a PC running Ubuntu. One of its fu
Hi
I apologize in advance for this is my first email using this mailing list but I
could really use some help. I have connected a composite USB device running the
4.0 Linux kernel to a PC running Ubuntu. One of its functions is to act as a
HID device for mouse and keyboard to control the host
On Tue, 2016-07-26 at 10:59 +, Sheng Li (李盛) wrote:
> it is about an usb error handling in function "hid_io_error":
>
> the comments shows
>
> /* Retries failed, so do a port reset unless we lack bandwidth*/
>
> but actually the code do the opposite
>
>
> Signed-off-by:Sheng Li
Hi,
it is about an usb error handling in function "hid_io_error":
the comments shows
/* Retries failed, so do a port reset unless we lack bandwidth*/
but actually the code do the opposite
Signed-off-by:Sheng Li
drivers/hid/usbhid/hid-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-
The GIGABYTE GA-970A-DS3 motherboard is broken because
Gigabyte did not qualify the hardware that they used.
The Etron Technology, Inc. EJ168 USB 3.0 Host Controller (rev 01)
does not properly handle USB hubs.
By adding a PCI-E controller card:
Renesas Technology Corp. uPD720201 USB 3.0 Host Co
On Fri, Jul 22, 2016 at 2:16 PM, Alan Stern wrote:
>> I'd suggest a comment referencing the spec then :)
>
> Don't be silly. Nobody could possibly understand the code without
> reading the spec first. There's no need to mention the spec in a
> comment; it's an obvious prerequisite.
I've managed
On Fri, 22 Jul 2016, Bruce Korb wrote:
> HI,
>
> On Fri, Jul 22, 2016 at 12:57 PM, Alan Stern
> wrote:
> > They come from the xHCI hardware.
>
> I'd suggest a comment referencing the spec then :)
Don't be silly. Nobody could possibly understand the code without
reading the spec first. Ther
HI,
On Fri, Jul 22, 2016 at 12:57 PM, Alan Stern wrote:
> They come from the xHCI hardware.
I'd suggest a comment referencing the spec then :)
> /* Completion Code - only applicable for some types of TRBs */
> #define COMP_CODE_MASK (0xff << 24)
> #define GET_COMP_CODE(p) (((p) & COMP_CODE_MASK
On Fri, 22 Jul 2016, Bruce Korb wrote:
> A few questions:
>
> 1. Where do the values for TRB completion codes come from?
> COMP_BW_ERR and COMP_2ND_BW_ERR seem to be defined
> and then only used in a switch statement.
They come from the xHCI hardware.
> 2. xhci_queue_configure_endpoint
A few questions:
1. Where do the values for TRB completion codes come from?
COMP_BW_ERR and COMP_2ND_BW_ERR seem to be defined
and then only used in a switch statement.
2. xhci_queue_configure_endpoint() seems to be the function for
sending down a command that somehow loads the "BW_E
On Thu, 21 Jul 2016, Bruce Korb wrote:
> It seems the problem is related to 64 bit Linux on Gigabyte motherboards.
> 32 bit? No problem. Windows? No problem. Another mobo? No problem.
> So much for buying the preferred Linux mobo.
> I've added the GRUB_CMDLINE_LINUX= change to /etc/default/grub
It seems the problem is related to 64 bit Linux on Gigabyte motherboards.
32 bit? No problem. Windows? No problem. Another mobo? No problem.
So much for buying the preferred Linux mobo.
I've added the GRUB_CMDLINE_LINUX= change to /etc/default/grub and
updated with "update-bootloader". I hope t
On Wed, 20 Jul 2016, Bruce Korb wrote:
> Hi Alan,
>
> I swapped the driver, so usb_device_supports_lpm() always returns "0".
> No change. Bandwidth for a Class 10 SSD, but not for a mouse or
FYI, a Class 10 SSD does not have any bandwidth requirement. If very
little bandwidth is available, th
Hi Alan,
I swapped the driver, so usb_device_supports_lpm() always returns "0".
No change. Bandwidth for a Class 10 SSD, but not for a mouse or
keyboard. There is a new message that I've not seen before,
hub_port_status failed (err = -71) === EPROTO
$ lsusb -t
/: Bus 02.Port 1: Dev 1, Clas
Hi Alan,
On Mon, Jul 18, 2016 at 6:09 PM, Alan Stern wrote:
>> Given the repeatability, maybe I can dig into where stuff is going awry.
>> Maybe I can trace down how the bogus speed information is derived.
>
> If my guess was correct, there is no bogus speed information.
OK.
>> I do not believe
On Mon, 18 Jul 2016, Bruce Korb wrote:
> On Mon, Jul 18, 2016 at 2:24 PM, Alan Stern wrote:
> > This is not surprising, because the problem probably stems from the
> > xHCI host controller in your computer, not from the hub.
>
> Gigabyte is supposed to make reliable motherboards.
> Haven't been
On Mon, Jul 18, 2016 at 2:24 PM, Alan Stern wrote:
> This is not surprising, because the problem probably stems from the
> xHCI host controller in your computer, not from the hub.
Gigabyte is supposed to make reliable motherboards.
Haven't been trying to use USB3 until now, but still
Given t
On Mon, 18 Jul 2016, Bruce Korb wrote:
> On Sun, Jul 17, 2016 at 12:43 PM, Alan Stern
> wrote:
> > A USB-3.1 device should work okay with a USB-3 driver. However, it
> > would help if you upgrade to the latest available kernel version.
>
> It is the latest available openSUSE release.
The rele
On Sun, Jul 17, 2016 at 12:43 PM, Alan Stern wrote:
> A USB-3.1 device should work okay with a USB-3 driver. However, it
> would help if you upgrade to the latest available kernel version.
It is the latest available openSUSE release.
I've downloaded the latest Slackware release. I'll try it la
On Sun, 17 Jul 2016, Bruce Korb wrote:
> On Sun, Jul 17, 2016 at 6:57 AM, Alan Stern wrote:
> >
> > What kernel version are you using?
>
> openSUSE's latest: 4.1.27
> Someone told me that the "05e3:0610 Genesys Logic, Inc" device is a
> USB 3.1 and the driver capable of handling it was released
On Sun, Jul 17, 2016 at 6:57 AM, Alan Stern wrote:
>
> What kernel version are you using?
openSUSE's latest: 4.1.27
Someone told me that the "05e3:0610 Genesys Logic, Inc" device is a
USB 3.1 and the driver capable of handling it was released _several_
days ago now. Perhaps I'm just not up-to-d
On Sat, 16 Jul 2016, Bruce Korb wrote:
> On Sat, Jul 16, 2016 at 4:18 PM, Greg KH wrote:
> >> [13043.528023] usb 1-1.3: Product: Gaming Mouse G400
> >> [13043.528027] usb 1-1.3: Manufacturer: Logitech
> >> [13043.528309] usb 1-1.3: Not enough bandwidth for new device state.
> >> [13043.528319] us
On Sat, Jul 16, 2016 at 4:33 PM, Greg KH wrote:
> That's not how USB protocols work, they are driven from the host, not
> the device, your computer is asking that keyboard if it constantly has
> new data, it's not driven by how fast or slow you type.
Not a USB person, I didn't know. I prefer "I
On Sat, Jul 16, 2016 at 04:27:05PM -0700, Bruce Korb wrote:
> On Sat, Jul 16, 2016 at 4:18 PM, Greg KH wrote:
> >> [13043.528023] usb 1-1.3: Product: Gaming Mouse G400
> >> [13043.528027] usb 1-1.3: Manufacturer: Logitech
> >> [13043.528309] usb 1-1.3: Not enough bandwidth for new device state.
>
On Sat, Jul 16, 2016 at 4:18 PM, Greg KH wrote:
>> [13043.528023] usb 1-1.3: Product: Gaming Mouse G400
>> [13043.528027] usb 1-1.3: Manufacturer: Logitech
>> [13043.528309] usb 1-1.3: Not enough bandwidth for new device state.
>> [13043.528319] usb 1-1.3: can't set config #1, error -28
>
> That's
On Sat, Jul 16, 2016 at 12:40:43PM -0700, Bruce Korb wrote:
> [13026.604365] usb 1-1.3: USB disconnect, device number 28
> [13043.430087] usb 1-1.3: new full-speed USB device number 32 using xhci_hcd
> [13043.528010] usb 1-1.3: New USB device found, idVendor=046d, idProduct=c245
> [13043.528018] us
I just found your address as a better one than linux-kernel:
***
My typing follows a line with a bunch of stars. That is followed by
command output.
***
I have a USB 3.0 hub and switch that I need to use to switch devices
between a Linux desktop, laptop and MacBook Pro. At first, I was
From: Kristian Evensen
There seems to be a new version of the Microchip Pick16F1454 with a
different PID (0xf2f7). This device should also be ignored by the HID
driver. The PID was observed with the second version of the Yepkit Ykush
USB hub.
Signed-off-by: Kristian Evensen
---
drivers/hid/hid
On Tue, 20 Jan 2015, Kristian Evensen wrote:
> The Microchip Pick16F1454 is exported as a HID device and is used by for
> example
> the Yepkit YKUSH three-port switchable USB hub. However, it is not an actual
> HID-device. On the Yepkit, it is used to power up/down the ports on the hub.
> The
>
The Microchip Pick16F1454 is exported as a HID device and is used by for example
the Yepkit YKUSH three-port switchable USB hub. However, it is not an actual
HID-device. On the Yepkit, it is used to power up/down the ports on the hub. The
HID driver should ignore this device.
Signed-off-by: Kristi
The upstream sources for platform/intel-mid aren't in any public git
repos and are distributed
as a tarball. I have been unable to find any platform/intel-mid
specific mailing lists, so
I created my own repos and tickets to track my progress. I haven't
done much work in the
kernel, but I'm trying
Hi Chris
On 2015-01-08 at 17:38:07 +0100, Chris McClimans wrote:
> I found your email in the commits for gadget_hid.txt and thought one of you
> might might be able to point me in the right direction. I'm trying to get
> the g_hid module working with the Intel Edison.
Please don't send such e-ma
W dniu 08.01.2015 o 18:09, Felipe Balbi pisze:
Hi,
On Thu, Jan 08, 2015 at 09:05:24AM -0800, Chris McClimans wrote:
I'm trying to get the g_hid module working with the Intel Edison.
I tried just compiling intel's patch(1) to 3.10.17 with
CONFIG_USB_GADGETFS=m CONFIG_USB_G_HID=m but I get an er
Hi,
On Thu, Jan 08, 2015 at 09:05:24AM -0800, Chris McClimans wrote:
> I'm trying to get the g_hid module working with the Intel Edison.
>
> I tried just compiling intel's patch(1) to 3.10.17 with
> CONFIG_USB_GADGETFS=m CONFIG_USB_G_HID=m but I get an error trying to
> load the module:
>
> modp
I'm trying to get the g_hid module working with the Intel Edison.
I tried just compiling intel's patch(1) to 3.10.17 with
CONFIG_USB_GADGETFS=m CONFIG_USB_G_HID=m but I get an error trying to
load the module:
modprobe: ERROR: could not insert 'g_hid': No such device
According to https://www.kern
Summary of how to test HID function of USB gadget.
Signed-off-by: Andrzej Pietrasiewicz
---
Documentation/usb/gadget-testing.txt | 47
1 file changed, 47 insertions(+)
diff --git a/Documentation/usb/gadget-testing.txt
b/Documentation/usb/gadget-testing.txt
Summary of how to test HID function of USB gadget.
Signed-off-by: Andrzej Pietrasiewicz
---
Documentation/usb/gadget-testing.txt | 47
1 file changed, 47 insertions(+)
diff --git a/Documentation/usb/gadget-testing.txt
b/Documentation/usb/gadget-testing.txt
Summary of how to test HID function of USB gadget.
Signed-off-by: Andrzej Pietrasiewicz
---
Documentation/usb/gadget-testing.txt | 47
1 file changed, 47 insertions(+)
diff --git a/Documentation/usb/gadget-testing.txt
b/Documentation/usb/gadget-testing.txt
oard/mouse?
>>
>> google usbmon
> Sorry for making you confused.
> What I need is not monitor usb bus data.
> What I need is some user mode program, and when I execute it, it will
> driver usb HID keyboard/mouse to work.
> And I can print out the hex value those device
ser mode program, and when I execute it, it will
driver usb HID keyboard/mouse to work.
And I can print out the hex value those device send once user press
any key on keyboard or moving mouse around.
It should be like I think
hid_device=hid_open(xxx);
while(1){
data = get input data(hid_device);
From: loody
> Is there any test program we can use to capture input data send from
> usb keyboard/mouse?
google usbmon
David
hi all:
Is there any test program we can use to capture input data send from
usb keyboard/mouse?
I don't need to parsing the binary sent by keyboard/mouse. Just raw
data is fine.
I checked the Kernel sample, hid-example.c, but it seems only get
report and print it out.
appreciate your help in adv
On Tue, Jun 24, 2014 at 03:10:43PM +0200, Bjørn Mork wrote:
> Johan Hovold writes:
>
> > This is a non-standard attribute of this particular laptop. It has three
> > individual LEDs that can be enabled separately (using standard LED class
> > attributes), but they will all three be in the same "m
Johan Hovold writes:
> This is a non-standard attribute of this particular laptop. It has three
> individual LEDs that can be enabled separately (using standard LED class
> attributes), but they will all three be in the same "mode" (which here
> apparently means that they can be fully on, vary wi
On Mon, Jun 23, 2014 at 04:24:48PM -0400, Greg KH wrote:
> On Mon, Jun 23, 2014 at 09:52:12PM +0200, Johan Hovold wrote:
> > On Mon, Jun 23, 2014 at 03:40:59PM -0400, Greg KH wrote:
> > > On Mon, Jun 23, 2014 at 09:31:34PM +0200, Johan Hovold wrote:
> > > > On Mon, Jun 23, 2014 at 02:24:32PM -0400,
On Mon, Jun 23, 2014 at 09:52:12PM +0200, Johan Hovold wrote:
> On Mon, Jun 23, 2014 at 03:40:59PM -0400, Greg KH wrote:
> > On Mon, Jun 23, 2014 at 09:31:34PM +0200, Johan Hovold wrote:
> > > On Mon, Jun 23, 2014 at 02:24:32PM -0400, Greg KH wrote:
> > > > On Mon, Jun 23, 2014 at 02:23:24PM -0400,
On Mon, Jun 23, 2014 at 03:40:59PM -0400, Greg KH wrote:
> On Mon, Jun 23, 2014 at 09:31:34PM +0200, Johan Hovold wrote:
> > On Mon, Jun 23, 2014 at 02:24:32PM -0400, Greg KH wrote:
> > > On Mon, Jun 23, 2014 at 02:23:24PM -0400, Greg KH wrote:
> > > > On Mon, Jun 23, 2014 at 08:16:48PM +0300, Jann
On Mon, Jun 23, 2014 at 09:31:34PM +0200, Johan Hovold wrote:
> On Mon, Jun 23, 2014 at 02:24:32PM -0400, Greg KH wrote:
> > On Mon, Jun 23, 2014 at 02:23:24PM -0400, Greg KH wrote:
> > > On Mon, Jun 23, 2014 at 08:16:48PM +0300, Janne Kanniainen wrote:
> > > > + ret = sysfs_create_group(&led
On Mon, Jun 23, 2014 at 02:24:32PM -0400, Greg KH wrote:
> On Mon, Jun 23, 2014 at 02:23:24PM -0400, Greg KH wrote:
> > On Mon, Jun 23, 2014 at 08:16:48PM +0300, Janne Kanniainen wrote:
> > > + ret = sysfs_create_group(&led->hdev->dev.kobj, >683r_attribute_group);
> > > + if (ret) {
> > > +
On Mon, Jun 23, 2014 at 08:16:48PM +0300, Janne Kanniainen wrote:
> + ret = sysfs_create_group(&led->hdev->dev.kobj, >683r_attribute_group);
> + if (ret) {
> + hid_err(hdev, "failed to create sysfs attributes\n");
> + goto fail;
> + }
No, you need to set the att
On Mon, Jun 23, 2014 at 02:23:24PM -0400, Greg KH wrote:
> On Mon, Jun 23, 2014 at 08:16:48PM +0300, Janne Kanniainen wrote:
> > + ret = sysfs_create_group(&led->hdev->dev.kobj, >683r_attribute_group);
> > + if (ret) {
> > + hid_err(hdev, "failed to create sysfs attributes\n");
> > +
On Mon, Jun 23, 2014 at 08:16:48PM +0300, Janne Kanniainen wrote:
> This driver adds support for USB controlled led panels that exists in
> MSI GT683R laptop
>
> Signed-off-by: Janne Kanniainen
> ---
> Changes in v2:
> - sorted headers to alphabetic order
> - using devm_kzalloc
>
This driver adds support for USB controlled led panels that exists in
MSI GT683R laptop
Signed-off-by: Janne Kanniainen
---
Changes in v2:
- sorted headers to alphabetic order
- using devm_kzalloc
- using BIT(n)
- using usb_control_msg instead of usb_submit_urb
>> Sorry for noticing this thread late.
No problem. Good that you noticed it now! Thank you.
> Just move the initialisation of the lock and work to the other private
> data initialisations directly after it's allocated.
>
> Can you send a follow up patch, Janne?
Yes I can. Just a moment.
Janne
On Mon, Jun 23, 2014 at 04:42:55PM +0200, Johan Hovold wrote:
> On Mon, Jun 23, 2014 at 04:35:13PM +0200, Oliver Neukum wrote:
> > On Wed, 2014-06-18 at 19:05 +0300, Janne Kanniainen wrote:
> > > This driver adds support for USB controlled led panels that exists in
> > > MSI GT683R laptop
> > >
>
On Mon, Jun 23, 2014 at 04:35:13PM +0200, Oliver Neukum wrote:
> On Wed, 2014-06-18 at 19:05 +0300, Janne Kanniainen wrote:
> > This driver adds support for USB controlled led panels that exists in
> > MSI GT683R laptop
> >
>
> > +static int gt683r_led_probe(struct hid_device *hdev,
> > +
On Wed, 2014-06-18 at 19:05 +0300, Janne Kanniainen wrote:
> This driver adds support for USB controlled led panels that exists in
> MSI GT683R laptop
>
> +static int gt683r_led_probe(struct hid_device *hdev,
> + const struct hid_device_id *id)
> +{
> + int i;
> + int
On Wed, 18 Jun 2014, Johan Hovold wrote:
> > This driver adds support for USB controlled led panels that exists in
> > MSI GT683R laptop
> >
> > Signed-off-by: Janne Kanniainen
>
> Reviewed-by: Johan Hovold
>
> Thanks, Janne!
Now applied. Thanks Janne for the driver, and thanks a lot Johan f
On Wed, Jun 18, 2014 at 09:41:35PM +0300, Janne Kanniainen wrote:
> >> This driver adds support for USB controlled led panels that exists in
> >> MSI GT683R laptop
> >>
> >> Signed-off-by: Janne Kanniainen
> >
> > Reviewed-by: Johan Hovold
> >
> > Thanks, Janne!
> >
> > Johan
>
> Thank you for r
>> This driver adds support for USB controlled led panels that exists in
>> MSI GT683R laptop
>>
>> Signed-off-by: Janne Kanniainen
>
> Reviewed-by: Johan Hovold
>
> Thanks, Janne!
>
> Johan
Thank you for reviewing my patch :) I sure learnt a
lot from you and if I ever send patch in future, it i
On Wed, Jun 18, 2014 at 07:05:02PM +0300, Janne Kanniainen wrote:
> This driver adds support for USB controlled led panels that exists in
> MSI GT683R laptop
>
> Signed-off-by: Janne Kanniainen
Reviewed-by: Johan Hovold
Thanks, Janne!
Johan
> ---
> Changes in v2:
> - sorted headers to
This driver adds support for USB controlled led panels that exists in
MSI GT683R laptop
Signed-off-by: Janne Kanniainen
---
Changes in v2:
- sorted headers to alphabetic order
- using devm_kzalloc
- using BIT(n)
- using usb_control_msg instead of usb_submit_urb
On Tue, Jun 17, 2014 at 07:41:44PM +0300, Janne Kanniainen wrote:
> This driver adds support for USB controlled led panels that exists in
> MSI GT683R laptop
>
> Changes in v2:
> - sorted headers to alphabetic order
> - using devm_kzalloc
> - using BIT(n)
> - using usb_cont
This driver adds support for USB controlled led panels that exists in
MSI GT683R laptop
Changes in v2:
- sorted headers to alphabetic order
- using devm_kzalloc
- using BIT(n)
- using usb_control_msg instead of usb_submit_urb
- removing unneeded code
Changes
On Tue, Jun 17, 2014 at 01:01:55AM +0300, Janne Kanniainen wrote:
> This driver adds support for USB controlled led panels that exists in
> MSI GT683R laptop
>
> Signed-off-by: Janne Kanniainen
> ---
> Changes in v2:
> - sorted headers to alphabetic order
> - using devm_kzalloc
>
This driver adds support for USB controlled led panels that exists in
MSI GT683R laptop
Signed-off-by: Janne Kanniainen
---
Changes in v2:
- sorted headers to alphabetic order
- using devm_kzalloc
- using BIT(n)
- using usb_control_msg instead of usb_submit_urb
This driver adds support for USB controlled led panels that exists in
MSI GT683R laptop
Signed-off-by: Janne Kanniainen
---
Changes in v2:
- sorted headers to alphabetic order
- using devm_kzalloc
- using BIT(n)
- using usb_control_msg instead of usb_submit_urb
On Sun, Jun 15, 2014 at 02:23:25AM +0300, Janne Kanniainen wrote:
> > Hi!
>
> Hi.
>
> >> --- /dev/null
> >> +++ b/Documentation/ABI/testing/sysfs-class-hid-driver-gt683r
> >> @@ -0,0 +1,10 @@
> >> +What:/sys/class/hidraw//device/state
> >> +Date:Jun 2014
> >> +Kern
On Sun, Jun 15, 2014 at 05:59:40PM +0300, Janne Kanniainen wrote:
> >> Ok, so you decided to continue setting mode on every LED brightness
> >> update. That should be fine, but you never answered my question about
> >> whether it is necessary?
> >
> > I decided to do it that way because official dr
>> Ok, so you decided to continue setting mode on every LED brightness
>> update. That should be fine, but you never answered my question about
>> whether it is necessary?
>
> I decided to do it that way because official driver did it as well. I
> can check if it is necessary.
Ok, I checked this o
> Hi!
Hi.
>> --- /dev/null
>> +++ b/Documentation/ABI/testing/sysfs-class-hid-driver-gt683r
>> @@ -0,0 +1,10 @@
>> +What:/sys/class/hidraw//device/state
>> +Date:Jun 2014
>> +KernelVersion: 3.15
>> +Contact: Janne Kanniainen
>> +Description:
>> +
On Thu 2014-06-12 23:34:12, Janne Kanniainen wrote:
> This driver adds support for USB controlled led panels that exists in
> MSI GT683R laptop
Hi!
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-class-hid-driver-gt683r
> @@ -0,0 +1,10 @@
> +What:/sys/class/hidraw//device
> Ok, so you decided to continue setting mode on every LED brightness
> update. That should be fine, but you never answered my question about
> whether it is necessary?
I decided to do it that way because official driver did it as well. I
can check if it is necessary.
> You're almost done. One la
On Thu, Jun 12, 2014 at 11:34:12PM +0300, Janne Kanniainen wrote:
> This driver adds support for USB controlled led panels that exists in
> MSI GT683R laptop
>
> Signed-off-by: Janne Kanniainen
> ---
> Changes in v2:
> - sorted headers to alphabetic order
> - using devm_kzalloc
>
This driver adds support for USB controlled led panels that exists in
MSI GT683R laptop
Signed-off-by: Janne Kanniainen
---
Changes in v2:
- sorted headers to alphabetic order
- using devm_kzalloc
- using BIT(n)
- using usb_control_msg instead of usb_submit_urb
On Thu, Jun 12, 2014 at 01:48:41AM +0300, Janne Kanniainen wrote:
> This driver adds support for USB controlled led panels that exists in MSI
> GT683R laptop
You forgot to break this line.
>
> Signed-off-by: Janne Kanniainen
> ---
> Changes in v2:
> - sorted headers to alphabetic order
This driver adds support for USB controlled led panels that exists in MSI
GT683R laptop
Signed-off-by: Janne Kanniainen
---
Changes in v2:
- sorted headers to alphabetic order
- using devm_kzalloc
- using BIT(n)
- using usb_control_msg instead of usb_submit_urb
On Wed, Jun 11, 2014 at 04:05:42PM +0200, Johan Hovold wrote:
>
On Wed, Jun 11, 2014 at 12:21:39AM +0300, Janne Kanniainen wrote:
> > +static int gt683r_led_snd_msg(struct gt683r_led *led, char *msg)
> > +{
> > + int ret;
> > +
> > + ret = hid_hw_raw_request(led->hdev, 0x01, msg, GT683R_BUFFER_
On Wed, Jun 11, 2014 at 04:05:42PM +0200, Johan Hovold wrote:
> On Wed, Jun 11, 2014 at 12:21:39AM +0300, Janne Kanniainen wrote:
> > +static const char gt683r_led_select_leds[GT683R_BUFFER_SIZE] = { 0x01,
> > 0x02, 0x30, 0x00,
> > +0x00
On Wed, Jun 11, 2014 at 01:25:49PM +0200, Jiri Kosina wrote:
> On Wed, 11 Jun 2014, Janne Kanniainen wrote:
>
> > This driver adds support for USB controlled led panels that exists in MSI
> > GT683R laptop
> >
> > Changes in v2:
> > - sorted headers to alphabetic order
> > - using devm_k
On Wed, Jun 11, 2014 at 12:21:39AM +0300, Janne Kanniainen wrote:
> This driver adds support for USB controlled led panels that exists in MSI
> GT683R laptop
Can you break this line by 72 columns or so as well?
> Changes in v2:
> - sorted headers to alphabetic order
> - using devm_kz
On Wed, 11 Jun 2014, Janne Kanniainen wrote:
> This driver adds support for USB controlled led panels that exists in MSI
> GT683R laptop
>
> Changes in v2:
> - sorted headers to alphabetic order
> - using devm_kzalloc
> - using BIT(n)
> - using usb_control_msg instead of
This driver adds support for USB controlled led panels that exists in MSI
GT683R laptop
Changes in v2:
- sorted headers to alphabetic order
- using devm_kzalloc
- using BIT(n)
- using usb_control_msg instead of usb_submit_urb
- removing unneeded code
Chang
On Sun, 16 Mar 2014, Peter Fassberg wrote:
> On Sat, 15 Mar 2014, Alan Stern wrote:
>
> > You may be able to get it to work by doing
> >
> > echo 0x 0x0002 >/sys/bus/usb/drivers/usbhid/new_id
>
> As I wroter earlier it did solve the problem.
>
> However, the Report Descriptors is "unava
On Sat, 15 Mar 2014, Alan Stern wrote:
You may be able to get it to work by doing
echo 0x 0x0002 >/sys/bus/usb/drivers/usbhid/new_id
As I wroter earlier it did solve the problem.
However, the Report Descriptors is "unavailable" now.
lsusb output:
Report Descriptors:
On Sat, 15 Mar 2014, Alan Stern wrote:
On Fri, 14 Mar 2014, Peter Fassberg wrote:
Hi!
I'm using quite a few USB HID devices, but one of them fail.
I have really no idea about what is going on here, and it's an odd
card (my geothermal heat pump).
Maybe you have an idea about why
On Fri, 14 Mar 2014, Peter Fassberg wrote:
> Hi!
>
> I'm using quite a few USB HID devices, but one of them fail.
>
> I have really no idea about what is going on here, and it's an odd
> card (my geothermal heat pump).
>
> Maybe you have an idea about why it
Hi!
I'm using quite a few USB HID devices, but one of them fail.
I have really no idea about what is going on here, and it's an odd card (my
geothermal heat pump).
Maybe you have an idea about why it doesn't get recognized by the HID driver?
VID/PID: 0x / 0x0002 :(
I have to admit that I'm
lost at this time, as this is my first journey into Linux driver land
and Linux USB HID territory... So in my simple mind I would think of
something like...
static int contour_input_mapped(struct hid_device *hdev, struct
hid_input *hi,
struct hid_field *f
On Sun, Mar 09, 2014 at 04:55:32PM +0100, Harald Albrecht wrote:
> I would like to improve support for the multimedia controllers from
> Contour company, as there currently get relative events swalled by input.c.
>
> The background: Contour seems to have messed up the USB HID descri
I would like to improve support for the multimedia controllers from
Contour company, as there currently get relative events swalled by input.c.
The background: Contour seems to have messed up the USB HID descriptions
of their multimedia controller devices in that these report to use
relative
1 - 100 of 150 matches
Mail list logo
