Most of the question here are already answered or no more actual, but
for clarity:
Jiri Slaby wrote:
The remote is visible to the system as a usb interrupt end point.
Interrupt endpoint tells the system the polling interval (by endpoint
report). From the USB specs on the interval:
The USB System Software will use this information during configuration
to determine a period that can be sustained. The period provided by
the system may be shorter than that desired by the device up to the
shortest period defined by the USB (125 µs microframe or 1 ms frame).
The client software and device can depend only on the fact that the
host will ensure that the time duration between two transaction
attempts with the endpoint will be no longer than the desired period.
As I understand it, in plain English it means that the polling interval
must not be longer than what the endpoint report says (in case of
full-speed endpoint 1 to 255 ms). This device in question, assuming it
gives the interval in full-speed mode even it really is high-speed
device, gives 16ms interval period.
However af9015.c/dvb-usb-remote.c accesses it as if it was a bulk
endpoint and with 150ms interval. I did not look further on if this is
the only reason or the reason for it not to work. But at least it is in
clear contradiction of the USB-specs.
To what statement is it in contradiction? The statement above is for
interrupt transfers.
The answer was that there is no contradiction since the 150 ms was for
the bulk endpoint (0/81). When writing this I thought af9015.c used the
HID endpoint (1/83), which is interrupt endpoint, as an bulk endpoint.
I suspect, to make it work, much of the code from hid-driver should be
copied to the device driver.
Which code? I see no code being copied.
I meant that to make af9015.c to use HID endpoint past HID layer would
require copying big parts from the HID layer to af9015.c. Again it was
due to the above misunderstanding on my part.
However I think that would be exactly the
wrong way to go. I think the whole idea of making for every device a
separated driver ignoring the common code already in the kernel is bad
architecture.
Common code does not work well here. Don't you see weird key repetitions
and similar?
No, it worked ok for me.
Patrick, Johannes, why was not dvb-usb-remote implemented rather as a
part of the HID layer?
Because it's for device specific drivers that uses vendor class endpoint
instead of the HID class endpoint.
Also it is wrong idea that you could/should detect the type of remote
controller based on the tv-stick. E.g with Haupauge TV-NOVA nearly any
remote works ok (e.g my panasonic tv remote). Every generic ir-receiver
sends also the manufacturer and model codes. Remote ir-to-code
translates should be based on that (there is a kind of generic layer for
that in linux kernel) and not on the tv-stick model at all (as in the
af9015 driver).
Sorry, I don't understand this paragraph. Could you rephrase?
This has been, it seems, the one of the very goals of IR input coding:
to make remotes other than the ones provided with tv-stick to work with
that same stick.
BTW I now recall how I got Afateck remote work as should. The driver
loads ir-to-code translate table to the stick. I changed the codes to
what made more sense.
Why you didn't push this upstream?
Well the driver was at the time not part of the standard kernel
(downloaded form Matti Palosaaris site). And I put there directly the
keycodes that worked with command line mplayer. No standard solution.
One problem here is that current HID layer is very sparse in the
information it passes on, really only a code. It should also convey the
precice id of the device so upper layer would be better able to deal
with events. One of my hobbies is flight simulator flying. I use X-plane
(excellent program). There is also a linux version. But the linux
joystick driver is far from adequate for it (also some joysticks, yokes
and pedals or some of their controls didn't work at all). So I use a
special kernel for which I rewrote big parts of the HID-driver and
input-driver and wrote completely new joystick driver. Now it works
quite decently. One problem is the kernel->user joystick driver
interface, but it can not be changed since that's what X-plane (and
others use). One thing I got to change for that was that HID does less
model specific processing and passes more event info to higher layer
without breaking the old HID-devices (same with the input layer), so
that the joystick layer could do more intelligent processing. I fixed
also some bugs and one design omission in the HID driver (e.g. some
force feedback joysticks uses that HID-specification, in standard kernel
there is some ad-hoc code for that purpose).
Can't be HID bus with a specific driver used instead now?
Well it could, but this way it is much less work and more generic. I use
many different joysticks, yokes and pedals. And with some generic
modifications and improvements into generic HID layer and generic input
layer all worked well. Only joystick layer got to be completely rewritten.
I did never put this upstream because by the time I got my own patches
integrated to the (new) kernel, the hid/input layer had developed so
much that the patches could no more be used in the latest kernel. So I
hand applied them again, and again kernel had moved on, and so on. Also
to argue for patches that cover several areas and several maintainers is
difficult, and changing a lot at once is always risky. So I gave up.
If anyone is interested, I could take a look again and see if the
changes could be argued and applied incrementally instead of one big bunch.
Pekka
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
