On Thu, Feb 04, 2010 at 04:07:36PM +0200, Pekka Sarnila wrote:
> Yes, my comment maybe criticizes more the basic architectural structure of
> usb putting it's own work up to higher layer. The only practical thing is
> that, if there is a non-HID device suffering from that FULLSPEED problem,
> th
Mauro Carvalho Chehab wrote:
Pekka Sarnila wrote:
So dvb is both as a place and a name misleading.
It happens that almost all tv products (analog or digital) come with some
IR support. But you can find also some products that are just IR.
That's why we're moving it to be outside the V4L
On Thu, Feb 04, 2010 at 07:33:22PM +0100, Jiri Slaby wrote:
> On 02/04/2010 07:14 PM, Dmitry Torokhov wrote:
> > On Thu, Feb 04, 2010 at 11:31:45AM +0100, Jiri Slaby wrote:
> > +
> >> +static int dvb_event(struct hid_device *hdev, struct hid_field *field,
> >> + struct hid_usage *usage, _
On 02/04/2010 07:14 PM, Dmitry Torokhov wrote:
> On Thu, Feb 04, 2010 at 11:31:45AM +0100, Jiri Slaby wrote:
> +
>> +static int dvb_event(struct hid_device *hdev, struct hid_field *field,
>> +struct hid_usage *usage, __s32 value)
>> +{
>> +/* we won't get a "key up" event */
>> +
On Thu, Feb 04, 2010 at 11:31:45AM +0100, Jiri Slaby wrote:
+
> +static int dvb_event(struct hid_device *hdev, struct hid_field *field,
> + struct hid_usage *usage, __s32 value)
> +{
> + /* we won't get a "key up" event */
> + if (value) {
> + input_event(field->hid
Pekka Sarnila wrote:
> The problem here is that at least afatech ir receiver has the ir code to
> key code build in, so trough HID you can use only the remote whose ir to
> key translate table has been loaded to the aftech device. Unless that
> can be easily controlled by the user HID is no good f
Mauro Carvalho Chehab wrote:
Pekka Sarnila wrote:
The problem using vendor class is that there is no standard. Each vendor
can define its own way using endpoints (and has done so e.g Logitech
joysticks). Thus each usb ir receiver must have its own specific driver.
However then you get the raw
Jarod Wilson wrote:
> On 02/04/2010 08:41 AM, Mauro Carvalho Chehab wrote:
>> Jiri Slaby wrote:
>>> On 02/04/2010 01:04 PM, Mauro Carvalho Chehab wrote:
> I have 2 dvb-t receivers and both of them need fullspeed quirk.
> Further
> disable_rc_polling (a dvb_usb module parameter) must be
On 02/04/2010 08:41 AM, Mauro Carvalho Chehab wrote:
Jiri Slaby wrote:
On 02/04/2010 01:04 PM, Mauro Carvalho Chehab wrote:
I have 2 dvb-t receivers and both of them need fullspeed quirk. Further
disable_rc_polling (a dvb_usb module parameter) must be set to not get
doubled characters now. And
Jiri Slaby wrote:
> On 02/04/2010 02:41 PM, Mauro Carvalho Chehab wrote:
>> The point is that it is better to name the function right since the
>> beginning.
>
> Sorry, I misunderstood you for the first time. It's .event member of
> hid_driver. Hence I named it dvb_event (or now rc_event or whate
Yes, my comment maybe criticizes more the basic architectural structure
of usb putting it's own work up to higher layer. The only practical
thing is that, if there is a non-HID device suffering from that
FULLSPEED problem, the quirk won't help it. Anyway in current kernel
structure usb layer do
Pekka Sarnila wrote:
> The problem using vendor class is that there is no standard. Each vendor
> can define its own way using endpoints (and has done so e.g Logitech
> joysticks). Thus each usb ir receiver must have its own specific driver.
> However then you get the raw ir codes. When using HID
On 02/04/2010 02:41 PM, Mauro Carvalho Chehab wrote:
> The point is that it is better to name the function right since the beginning.
Sorry, I misunderstood you for the first time. It's .event member of
hid_driver. Hence I named it dvb_event (or now rc_event or whatever).
The function may contain
Jiri Slaby wrote:
> On 02/04/2010 01:04 PM, Mauro Carvalho Chehab wrote:
>>> I have 2 dvb-t receivers and both of them need fullspeed quirk. Further
>>> disable_rc_polling (a dvb_usb module parameter) must be set to not get
>>> doubled characters now. And then, it works like a charm.
>> Module para
On Thu, 4 Feb 2010, Pekka Sarnila wrote:
> The FULLSPEED thing is really not ir receiver specific problem. It can
> happen with any device with interrupt endpoint. That's the reason why I
> placed the quirk to HID driver.
>
> However even the HID driver is logically a wrong place. Really it sho
Well the thing is that this device (afatech) offers two different ways
to read the remote: vendor class bulk endpoint (0/81, used afatech
driver) and HID class interrupt endpoint (1/83, seen as an ordinary usb
keyboard by the usb/hid system). When I used unmodified kernel (with new
firmware) bo
On 02/04/2010 01:04 PM, Mauro Carvalho Chehab wrote:
>> I have 2 dvb-t receivers and both of them need fullspeed quirk. Further
>> disable_rc_polling (a dvb_usb module parameter) must be set to not get
>> doubled characters now. And then, it works like a charm.
>
> Module parameters always bothers
Jiri Slaby wrote:
> On 01/26/2010 02:08 PM, Jiri Kosina wrote:
>>> In my understanding the cause of the remote problem is chipset bug which
>>> sets
>>> USB2.0 polling interval to 4096ms. Therefore HID remote does not work at all
>>> or starts repeating. It is possible to implement remote as polli
On 01/26/2010 02:08 PM, Jiri Kosina wrote:
>> In my understanding the cause of the remote problem is chipset bug which sets
>> USB2.0 polling interval to 4096ms. Therefore HID remote does not work at all
>> or starts repeating. It is possible to implement remote as polling from the
>> driver which
On Mon, 25 Jan 2010, Antti Palosaari wrote:
> > What happens if you disable the HID layer? Or at least if you add an
> > ignore quirk for the device in usbhid?
>
> Looks like Fedora doesn't have usbhid compiled as module. I looked
> hid-quirks.c file and there was only one af9015 device blacklist
On 01/25/2010 11:12 AM, Jiri Slaby wrote:
On 01/25/2010 12:44 AM, Antti Palosaari wrote:
When I now test this patch with debugs enabled I don't see
.probe and .disconnect be called for this HID interface (interface 1) at
all and thus checks not needed.
What happens if you disable the HID layer
On 01/25/2010 12:44 AM, Antti Palosaari wrote:
> When I now test this patch with debugs enabled I don't see
> .probe and .disconnect be called for this HID interface (interface 1) at
> all and thus checks not needed.
What happens if you disable the HID layer? Or at least if you add an
ignore quirk
On 01/20/2010 07:19 PM, Jiri Slaby wrote:
When both remote controller and receiver intfs are handled by
af9015, .probe do nothing for remote intf, but when .disconnect
is called for both of them it touches intfdata every time. For
remote it crashes obviously (as intfdata are unset).
Altough ther
When both remote controller and receiver intfs are handled by
af9015, .probe do nothing for remote intf, but when .disconnect
is called for both of them it touches intfdata every time. For
remote it crashes obviously (as intfdata are unset).
Altough there is test against data being NULL, it is not
24 matches
Mail list logo
