linux-kernel - Re: [PATCH 1/1] media: dvb-usb/af9015, fix disconnection crashes

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <4B6C2BDD.80002@adit.fi>
Date:	Fri, 05 Feb 2010 16:31:57 +0200
From:	Pekka Sarnila <sarnila@...t.fi>
To:	Mauro Carvalho Chehab <mchehab@...hat.com>
CC:	Jiri Slaby <jirislaby@...il.com>, Jiri Kosina <jkosina@...e.cz>,
	Antti Palosaari <crope@....fi>, mchehab@...radead.org,
	linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
	linux-input@...r.kernel.org
Subject: Re: [PATCH 1/1] media: dvb-usb/af9015, fix disconnection crashes

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/