Prev: [Bug #14783] Unhandled IRQ on Thinkpad R61i: "irq 16: nobody cared"
Next: media: dvb/af9015, refactor remote setting
From: Dmitry Torokhov on 4 Feb 2010 13:50
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, __s32 value)
> >> +{
> >> + /* we won't get a "key up" event */
> >> + if (value) {
> >> + input_event(field->hidinput->input, usage->type, usage->code, 1);
> >> + input_event(field->hidinput->input, usage->type, usage->code, 0);
> >
> > Do not ever forget input_sync(), you need 2 of them here.
> >
> > With the latest changes to evdev, if you are using SIGIO you won't get
> > wioken up until EV_SYN/SYN_REPORT.
>
> HID layer syncs on its own. So the second is not needed. Why is needed
> the first?
>

Userpsace has a right to accumulate events and only act on them when
receiving EV_SYN. Press + release in the same event block may be treated
as no change. The same as REL_X +2, REL_X -2 - no need to move pointer at
all. And so on.

> I.e. should there be one also in dvb_usb_read_remote_control?

Probably, I have not looked.

--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Pekka Sarnila on 5 Feb 2010 09:40


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 and the DVB directory.
> For now, it is at /drivers/media/IR (since it helps us to move the code, while
> there are still some dependencies at ir-common). But the better is to move it
> later to /drivers/IR or /drivers/input/IR.

I was referring to the dvb-usb-remote. I think it's right place should
not be under dvb but under usb/remotes. If you have an usb remote device
that has nothing to do with audio-video, it would be strange to have its
driver under dvb. Dvb is a protocol name and should be used us such in
linux kernel as well. Otherwise it is misleading.

>>Well I was talking about HID remotes that don't give ir codes but key
>>codes. What to do with them?
>
> What happens if you use it to receive keycodes from a different IR using
> the same protocol?

Nothing. It responds only to those codes that are at the moment loaded
into its internal table.

> Maybe it can still be valid to keep allowing keycode translation.

Yes, provided that it can translate also keyboard keycodes to some other
keycodes.

> Well, as HID, you may loose the capability of using a different IR than the
> one shipped with the af9015. It may make sense to just disable HID and use
> USB Vendor Class.

Yes, that is the question. Both ways have good arguments for.

>>The thing is that remote controller trough HID layer does not provide IR
>>keycode but standard keyboard key code. And HID layer does not know that
>>it is a remote controller but sees it as an ordinary usb keyboard. The
>>question is that how can it tell the upper layer that it really is a
>>remote controller so that the event would end up to generic ir-core.
>
> For HID remote controllers, the only way I see is to have an USB ID list of devices
> that are known to be remote controllers and register them via ir_input_register,
> instead of input_register_device.

Well, the current kernel architecture for input devices is so, that a
higher layer generic driver registers a handler with the input layer
telling by the way of capabilities what kind deices it is willing to
handle. Lower layer devices drivers register with the input layer
telling it what kind of capabilities they have. Based on that the input
layer finds a match and relays events accordingly. Although arguments
against this mechanism can be found, one of its good sides is that it
completely separates generic device layer from device driver layer. E.g.
the coder of mouse layer does not need to know anything about various
mouse device drivers and vv. This is very good for the highly
distributed way linux is being developed.

IMHO ir remote controller receivers should be no exception to that. So
rather than use separate ir_input_register, a generic remote controller
layer (not only IR code based) should register a handler with the input
layer with suitable capabilities, and all remote controller device
drivers should register with the input layer telling by capabilities
that they are remote controllers. They would send events in standard way
to the input layer. Input layer would do the rest as normally.

Also in naming, due consideration should be given to the fact that IR
can be used for other type of communication as well.

> Cheers,
> Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Greg KH on 8 Feb 2010 17:40
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,
> the quirk won't help it. Anyway in current kernel structure usb layer
> doesn't handle endpoint setup at all, thus it simply can not do the job.

Patches to the USB core to resolve this issue are always gladly
appreciated :)

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: [Bug #14783] Unhandled IRQ on Thinkpad R61i: "irq 16: nobody cared"
Next: media: dvb/af9015, refactor remote setting