[Howto] USB sniffing
SniffUSB tool:
http://www.pcausa.com/Utilities/UsbSnoop/
Important blog article by crope:
http://blog.palosaari.fi/2013/07/generating-rtl2832u-driver-code.html
IRC log with crope and mchehab about USB sniffing:
[11:06am] crope_: mchehab: ping. I have one RTL2830 driver 3.12 regression. I suspect it is coming from I2C changes, but problem is here that I2C subsystem maintainer has not answered to mails....
[11:07am] crope_: it is that https://patchwork.kernel.org/patch/3079491/
[11:07am] crope_: maybe it could be still safe to marge that patch even I am not sure why it is needed
[11:16am] dddtest_e9d3d joined the chat room.
[11:24am] mchehab: crope_: hmm... khali is on this channel
[11:27am] mchehab: if just re-adding "priv->tuner_i2c_adapter.dev.parent = &i2c->dev;" is enough to fix it, go for it
[11:37am] crope_: mchehab: I2C maitainer *just* replied
[11:37am] crope_: and he says there should be parent, but it is unclear why it has not been crashed earlier
[11:38am] crope_: mchehab: any possibility to get it in late 3.12-RC ?
[11:39am] mchehab: crope_: I think that there were some patches removing the parent
[11:39am] mchehab: at least I remember something like that
[11:40am] mchehab: bbiab
[11:40am] kaspter left the chat room. (Remote host closed the connection)
[11:42am] khali: mchehab, crope: hi
[11:43am] khali: ah, I know the bug
[11:43am] khali: I already hit it myself and complained about it
[11:43am] khali: and provided a fix
[11:43am] john3voltas joined the chat room.
[11:43am] khali: should be upstream already...
[11:43am] crope_: mchehab: no there was no changes done RTL2830 driver. it just started crashing now after ~2 years
[11:43am] crope_: khali: looked the patchwork mail?
[11:44am] khali: crope_: the fix is here: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=47b6e477ed4ecacddd1f82d04d686026e08dc3db
[11:44am] khali: it's upstream since 3.12-rc5
[11:45am] crope_: khali: haha, ok, Wolfram didnt remember that patch
[11:45am] khali: you're lucky I stepped by
[11:45am] crope_: I am running media master which is 3.12-rc2
[11:45am] khali: I don't even remember why I joined ^^
[11:46am] khali: that being said, it is better for i2c-adapters to have a parent whenever possible, for a variety of reasons
[11:46am] crope_: so basically, that patch should not be even needed for 3.12 and it could be delayed to 3.13 then
[11:46am] khali: so fixing the RTL2830 driver would still be a good idea
[11:46am] khali: crope_: the RTL2830 driver patch is not immediately needed, you are right
[11:47am] crope_: yeah, that will go 3.13 and 3.12 as so late that better not to send unneeded patches as otherwise someone goes very angry
[11:47am] khali: yeah, I've see that before...
[11:52am] john3voltas left the chat room. (Quit: john3voltas)
[11:53am] john3voltas joined the chat room.
[11:57am] mchehab: crope_, khali: yeah, let's put that patch to 3.13, eventually c/c stable, if it is broken for <3.12
[11:59am] crope_: I tested F20 stock Kernel 3.11 and it works. 3.12 was the first time I saw that issue
[11:59am] khali: mchehab: the code change which triggered the problem went in with 3.12-rc1 - kernels < 3.12 aren't affected
[11:59am] mchehab: hmm... then, as 3.12-rc5 contains the fix, there's no need to backport
[12:01pm] mchehab: khali: what happens when parent is set?
[12:01pm] crope_: why it is needed?
[12:02pm] crope_: should parent be device below the adapter? so if I have USB interface and there is I2C adapter then parent is usb device?
[12:12pm] khali: mchehab: the device gets to the right place in the device tree
[12:13pm] khali: mchehab: which helps with things like power management, power down/up during suspend/resume, etc.
[12:13pm] khali: crope_: yes, you got it
[12:13pm] mchehab: ok, so it is important to have....
[12:13pm] khali: it's fairly simple and logical, nothing fancy
[12:14pm] mchehab: IMHO, you should add a WARN_ON() at i2c core if it is not defined...
[12:14pm] mchehab: to warn developers to add it at the drivers
[12:14pm] khali: as a bonus, sensors-detect for example will refuse to probe an i2c adapter if parent is a multimedia device
[12:14pm] khali: I added that for safety
[12:15pm] khali: mchehab: the problem is that we have one virtual adapter (i2c-stub) which has no parent and can't have any, 'cause it's virtual
[12:15pm] khali: so the WARN_ON you suggest would trigger for it...
[12:15pm] khali: unless we had a special flag "I don't have a parent and it's OK" and i2c-core checks for it...
[12:16pm] khali: add* sorry
[12:16pm] mchehab: another alternative would be to add some rule for it at checkpatch...
[12:16pm] mchehab: not sure if writing such rule would be simple
[12:23pm] khali: I don't think this is what checkpatch is good for
[12:23pm] khali: it's really a per-line checker
[12:24pm] khali: coccinelle would be better at that than checkpatch
[12:31pm] crope_: I think current situation is OK, as if someone adds new I2C adapter he really finds something is wrong when adapter register function crashes kernel
[12:32pm] john3voltas: hi guys
[12:32pm] john3voltas: mchehab: crope told me that you did the driver for rtl2832u+820t, right?
[12:33pm] mchehab: yep
[12:33pm] crope_: john3voltas: mauro did r820t and you has some performance problems that are likely from the tuner
[12:33pm] john3voltas: exactly
[12:34pm] john3voltas: i have noticed that using my rtl2832i+r820t in windows is muuuuuch better than in linux
[12:34pm] john3voltas: it is a huge difference
[12:34pm] john3voltas: crope told me to use sniffusb but it only work on xp and i am on 7
[12:34pm] mchehab: john3voltas: as crope_ explained, I did the r820t driver and the bindings on rtl2832u to use it...
[12:35pm] mchehab: based on a previous work on userspace, from rtl
[12:35pm] john3voltas: i see
[12:35pm] john3voltas: have you tried it on windows and linux to see if you notice any difference?
[12:35pm] mchehab: no, I didn't
[12:35pm] john3voltas: hmmm
[12:36pm] mchehab: crope's suggestion is the way to go: you need to sniff the USB traffic on m$, in order to see what their driver are doing there
[12:36pm] john3voltas: yep
[12:36pm] john3voltas: but i've tried on a virtualbox VM and sniffusb doesn't seem to work
[12:36pm] crope_: I use that tuner very often for live signals and from my experience its performance is not that bad. still maybe a little bit worse than latest e4000
[12:37pm] mchehab: if you can run it on KVM, you can sniff the USB on Linux
[12:37pm] mchehab: I wrote some scripts for that...
[12:37pm] mchehab: it is at contrib dir at v4l2-utils
[12:37pm] john3voltas: kvm? never used it
[12:37pm] mchehab: it is possible that it could also work with virtualbox...
[12:37pm] mchehab: if virtualbox is using the Linux USB stack
[12:37pm] john3voltas: it is
[12:38pm] john3voltas: i can actually see the dongle in the xp vm
[12:38pm] mchehab: so, you can sniff the traffic then
[12:39pm] john3voltas: well yea but apparently i don't have enough cpu to be running sniffusb AND the windows tuner software
[12:39pm] john3voltas: inside the VM
[12:39pm] john3voltas: mchehab: you wouldn't be Portuguese or Brasilian, would ya?
[12:39pm] mchehab: vm performance sucks for DVB, but still you may be able to get the logs
[12:39pm] mchehab: Brazilian
[12:39pm] john3voltas: legal
[12:39pm] john3voltas: i'm portuguese
[12:39pm] john3voltas: ok
[12:39pm] mchehab: nice
[12:40pm] john3voltas: if you say that i can try it even without image
[12:40pm] john3voltas: then i can try to sniff
[12:40pm] mchehab: we used to have one Portuguese contributor on V4L2
[12:41pm] mchehab: yes, the tuner setup occurs before the streaming...
[12:41pm] mchehab: so, on most cases, you can get the proper logs
[12:41pm] john3voltas: do you think i can sniff it and send it to you guys to take a look?
[12:41pm] mchehab: even when there's no image
[12:42pm] john3voltas: because i can't understand anything it outputs
[12:42pm] _abbenormal left the chat room. (Ping timeout: 240 seconds)
[12:42pm] mchehab: well, if you use my scripts, its output is basically the stuff written to r820t
[12:42pm] mchehab: you can even compare it with the stuff written on Linux and see what's different
[12:43pm] mchehab: I won't have much available time to dig into it on November...
[12:43pm] crope_: it is a little bit hard to look sniffs... I used scripts to generate C-code for r820t driver when I find out bug it didint worked for r828d tuner (this week)
[12:43pm] mchehab: as we are about to open a merge window
[12:43pm] mchehab: crope_: feel free to add those scripts to contrib at v4l-utils
[12:44pm] mchehab: we have there similar scripts for em28xx, for example, that also generates a C-like code
[12:45pm] crope_: yeah, we could do better job to release those scripts... but time is always short. I think there is tons of these scripts for every developer hard disk
[12:45pm] john3voltas: well unfortunately i know nothing about scripting. which means that i most probably won't be able to understand it without some help
[12:45pm] crope_: john3voltas: here is script you will need http://blog.palosaari.fi/2013/07/generating-rtl2832u-driver-code.html
[12:46pm] john3voltas: for now i'll focus on getting the sniffs to a file
[12:46pm] mchehab: crope_: the ones I use I generally add there at contrib
[12:46pm] crope_: john3voltas: but it eats SniffUSB format. so you will basically need one script to convert your sniff first to "parser.pl" format
[12:46pm] john3voltas: wow
[12:47pm] john3voltas: guys i am a linux noob
[12:47pm] john3voltas: i'll read it
[12:47pm] john3voltas: will do my best to understand it
[12:47pm] john3voltas: but in the end i will probably cry for your help
[12:48pm] mchehab: http://git.linuxtv.org/v4l-utils.git/blob/HEAD:/contrib/parse-sniffusb2.pl should do that trick
[12:48pm] mchehab: hmm... it does the reverse
[12:49pm] john3voltas: boss is calling me. nice chatting with you guys. if you want to tell me something after i'm gone, go ahead and write it. i always look at the channel's logs
[12:49pm] john3voltas: thanks a bunch
[12:49pm] john3voltas: c ya
[12:49pm] john3voltas left the chat room.
[12:49pm] crope_: here is simple patch, just for that r820t tuner, where I have used code generated by sctipts to find out bug http://palosaari.fi/linux/v4l-dvb/rtl2832p_dvbt_hack.patch
[12:51pm] crope_: it is usually quite trivial task to find out problematic registers using that technique - when you have starting point where linux driver does not work, but windows driver works
[12:51pm] mchehab: crope_: john3voltas left the chat
[12:52pm] awalls: ls
[12:53pm] awalls: oops, wrong window
[12:54pm] _abbenormal joined the chat room.
[1:15pm] crope_: mchehab: btw. as I added that RTL2832P + R828D support, I noticed R820T has likely big problems with power consumption (it does not seems to go sleep properly)
[1:15pm] mchehab: yes, I saw your patches. They look sane to me
[1:17pm] crope_: I deleted those power measurements, but IIR it was mayne even near ~200mA when idle. but I could look that issue later... I should take one weekend and try to fix those USB power management bugs .... there is very much. what I have measured it is very rare that dvb usb has working power management (only some of those newers likely what I have implemented)
[1:19pm] crope_: merbanan: noticed I added basic support for RTL2832P + R828D?
[1:20pm] devinheitmueller: crope_: would take much longer than a weekend to fix those problems - they are all over the codebase (tuners, demods, video decoders, etc)
[1:21pm] devinheitmueller: Power down the bridge and in many drivers the state of the driver gets out of sync with the state of the actual chip.
[1:22pm] devinheitmueller: …many drivers take shortcuts such as "don't change the modulation if it's already set to what the driver thinks is the current value".
[1:22pm] devinheitmueller: Enable power management in the bridge and you'll expose all sorts of bugs in the other drivers.
[1:23pm] crope_: devinheitmueller: yeah but there is even simple bugs that software sleeps are not working properly. I mean the I2C command send to chip that put chip sleep / standby
[1:24pm] devinheitmueller: Using a chip level sleep call typically exposes cases where the driver fails to wake the chip back up for all the possible entry points.
[1:24pm] devinheitmueller: It's similar to issues with i2c gates - you have to be careful to ensure every code path actually opens/closes the gate.
[1:24pm] crope_: GPIO based RST PIN sleeps are other issue as it resets whole chip. that should be implemented like those embedded guys did - using clock framework, GPIO framework and regulator framework, in order to define standard interfaces
[1:25pm] devinheitmueller: Good luck doing that reliably.
[1:25pm] crope_: :S
[1:25pm] devinheitmueller: That said, I do believe the drivers should be informed when something external yanks the reset line, so at least the driver has an opportunity to reset its internal state.
[1:25pm] crope_: current em28xx clock is maybe the first try and there has been that a lot problems...
[1:26pm] devinheitmueller: Imagine my surprise.
[1:28pm] crope_: there is still some easy parts to start. those DVB only tuners are most easiest / safest place to start
[1:28pm] devinheitmueller: Almost certainly. Not having to worry about hybrid devices with analog reduces complexity enormously.
[1:45pm] mrec: empia is dead anyway I wonder if they still have any hybrid market share
[1:48pm] mrec: their boss is about to retire (or mentally already retired) they only live from the cash they made in the past now
[1:48pm] mrec: until they're completely gone
[1:49pm] crope_: did empia made some other that pctv bridges / reference designs?
[1:49pm] mrec: they stopped
[1:49pm] mrec: no customers in that area
[1:49pm] mrec: pctv market crashed for them as well
[1:50pm] mrec: just see hauppauge, pctv systems, terratec they're all kind of down now
[1:50pm] mrec: the main thing they do is cameras now but that barelly can stand the current cost they have
[1:55pm] mrec: http://sundtek.de/images/pcb_640.jpg
[1:55pm] mrec: next hybrid cards
[1:56pm] crope_: for analog tv?
[1:56pm] mrec: DVB-C/T/T2/FM/Composite/S-Video (DAB+/FM HD is also upcoming)
[1:56pm] mrec: as well as DVB-C2
[1:57pm] mrec: AnalogTV of course
[1:57pm] crope_: selling to africa those devices I think
[1:57pm] wgreenhouse left the chat room. (Ping timeout: 240 seconds)
[2:00pm] mrec: dual dvb-c/T/t2 stick will be interesting
[2:00pm] mrec: R&D is currently working on it
[2:01pm] mrec: much nicer to do those things directly in Berlin nowadays
[2:04pm] crope_: usb-bub + 2 bridges?
[2:05pm] mrec: single bridge
[2:06pm] mrec: we're evaluating to put on some small fpga to lower the bandwidth as well
[2:08pm] crope_: how did you think fpga lowers bw? custom pid filtering
[2:09pm] crope_: and fpga is still quite expensive, eats power too
[2:11pm] mrec: several companies are using FPGAs nowadays for their designs.
[2:12pm] crope_: one fpga has a price more than cheapest 3-in-1 usb dtv chip
[2:12pm] mrec: well I'm gone.
[2:12pm] crope_: yeah, surely, if you has volume less than 100 000 000 pieces it is cheaper to use fpga than asic
[2:12pm] mrec: not everyone is interested in selling devices for 10$ and trying to make money from 10$ devices.
[2:22pm] john3voltas joined the chat room.
[2:23pm] john3voltas: is mrnicelinuxtv missing?
[2:23pm] john3voltas: no logs since yesterday
[2:24pm] devinheitmueller: john3voltas: it crashes periodically and needs to be restarted manually.
[2:24pm] john3voltas: oh
[2:24pm] devinheitmueller: I typically bug mkrufky when I notice it's down.
[2:24pm] devinheitmueller: (and he logs in to linuxtv.org's server and restarts it)
[2:25pm] john3voltas: he's not online
[2:25pm] devinheitmueller: nope.
[2:26pm] devinheitmueller: john3voltas: I just pinged him via email to restart the loggers.
[2:26pm] john3voltas: thanks mate
[2:26pm] devinheitmueller: np
[2:27pm] john3voltas: unfortunately i was trying to read a chat from earlier today with crope and mchehab and this way it will be impossible
http://www.pcausa.com/Utilities/UsbSnoop/
Important blog article by crope:
http://blog.palosaari.fi/2013/07/generating-rtl2832u-driver-code.html
IRC log with crope and mchehab about USB sniffing:
[11:06am] crope_: mchehab: ping. I have one RTL2830 driver 3.12 regression. I suspect it is coming from I2C changes, but problem is here that I2C subsystem maintainer has not answered to mails....
[11:07am] crope_: it is that https://patchwork.kernel.org/patch/3079491/
[11:07am] crope_: maybe it could be still safe to marge that patch even I am not sure why it is needed
[11:16am] dddtest_e9d3d joined the chat room.
[11:24am] mchehab: crope_: hmm... khali is on this channel
[11:27am] mchehab: if just re-adding "priv->tuner_i2c_adapter.dev.parent = &i2c->dev;" is enough to fix it, go for it
[11:37am] crope_: mchehab: I2C maitainer *just* replied
[11:37am] crope_: and he says there should be parent, but it is unclear why it has not been crashed earlier
[11:38am] crope_: mchehab: any possibility to get it in late 3.12-RC ?
[11:39am] mchehab: crope_: I think that there were some patches removing the parent
[11:39am] mchehab: at least I remember something like that
[11:40am] mchehab: bbiab
[11:40am] kaspter left the chat room. (Remote host closed the connection)
[11:42am] khali: mchehab, crope: hi
[11:43am] khali: ah, I know the bug
[11:43am] khali: I already hit it myself and complained about it
[11:43am] khali: and provided a fix
[11:43am] john3voltas joined the chat room.
[11:43am] khali: should be upstream already...
[11:43am] crope_: mchehab: no there was no changes done RTL2830 driver. it just started crashing now after ~2 years
[11:43am] crope_: khali: looked the patchwork mail?
[11:44am] khali: crope_: the fix is here: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=47b6e477ed4ecacddd1f82d04d686026e08dc3db
[11:44am] khali: it's upstream since 3.12-rc5
[11:45am] crope_: khali: haha, ok, Wolfram didnt remember that patch
[11:45am] khali: you're lucky I stepped by
[11:45am] crope_: I am running media master which is 3.12-rc2
[11:45am] khali: I don't even remember why I joined ^^
[11:46am] khali: that being said, it is better for i2c-adapters to have a parent whenever possible, for a variety of reasons
[11:46am] crope_: so basically, that patch should not be even needed for 3.12 and it could be delayed to 3.13 then
[11:46am] khali: so fixing the RTL2830 driver would still be a good idea
[11:46am] khali: crope_: the RTL2830 driver patch is not immediately needed, you are right
[11:47am] crope_: yeah, that will go 3.13 and 3.12 as so late that better not to send unneeded patches as otherwise someone goes very angry
[11:47am] khali: yeah, I've see that before...
[11:52am] john3voltas left the chat room. (Quit: john3voltas)
[11:53am] john3voltas joined the chat room.
[11:57am] mchehab: crope_, khali: yeah, let's put that patch to 3.13, eventually c/c stable, if it is broken for <3.12
[11:59am] crope_: I tested F20 stock Kernel 3.11 and it works. 3.12 was the first time I saw that issue
[11:59am] khali: mchehab: the code change which triggered the problem went in with 3.12-rc1 - kernels < 3.12 aren't affected
[11:59am] mchehab: hmm... then, as 3.12-rc5 contains the fix, there's no need to backport
[12:01pm] mchehab: khali: what happens when parent is set?
[12:01pm] crope_: why it is needed?
[12:02pm] crope_: should parent be device below the adapter? so if I have USB interface and there is I2C adapter then parent is usb device?
[12:12pm] khali: mchehab: the device gets to the right place in the device tree
[12:13pm] khali: mchehab: which helps with things like power management, power down/up during suspend/resume, etc.
[12:13pm] khali: crope_: yes, you got it
[12:13pm] mchehab: ok, so it is important to have....
[12:13pm] khali: it's fairly simple and logical, nothing fancy
[12:14pm] mchehab: IMHO, you should add a WARN_ON() at i2c core if it is not defined...
[12:14pm] mchehab: to warn developers to add it at the drivers
[12:14pm] khali: as a bonus, sensors-detect for example will refuse to probe an i2c adapter if parent is a multimedia device
[12:14pm] khali: I added that for safety
[12:15pm] khali: mchehab: the problem is that we have one virtual adapter (i2c-stub) which has no parent and can't have any, 'cause it's virtual
[12:15pm] khali: so the WARN_ON you suggest would trigger for it...
[12:15pm] khali: unless we had a special flag "I don't have a parent and it's OK" and i2c-core checks for it...
[12:16pm] khali: add* sorry
[12:16pm] mchehab: another alternative would be to add some rule for it at checkpatch...
[12:16pm] mchehab: not sure if writing such rule would be simple
[12:23pm] khali: I don't think this is what checkpatch is good for
[12:23pm] khali: it's really a per-line checker
[12:24pm] khali: coccinelle would be better at that than checkpatch
[12:31pm] crope_: I think current situation is OK, as if someone adds new I2C adapter he really finds something is wrong when adapter register function crashes kernel
[12:32pm] john3voltas: hi guys
[12:32pm] john3voltas: mchehab: crope told me that you did the driver for rtl2832u+820t, right?
[12:33pm] mchehab: yep
[12:33pm] crope_: john3voltas: mauro did r820t and you has some performance problems that are likely from the tuner
[12:33pm] john3voltas: exactly
[12:34pm] john3voltas: i have noticed that using my rtl2832i+r820t in windows is muuuuuch better than in linux
[12:34pm] john3voltas: it is a huge difference
[12:34pm] john3voltas: crope told me to use sniffusb but it only work on xp and i am on 7
[12:34pm] mchehab: john3voltas: as crope_ explained, I did the r820t driver and the bindings on rtl2832u to use it...
[12:35pm] mchehab: based on a previous work on userspace, from rtl
[12:35pm] john3voltas: i see
[12:35pm] john3voltas: have you tried it on windows and linux to see if you notice any difference?
[12:35pm] mchehab: no, I didn't
[12:35pm] john3voltas: hmmm
[12:36pm] mchehab: crope's suggestion is the way to go: you need to sniff the USB traffic on m$, in order to see what their driver are doing there
[12:36pm] john3voltas: yep
[12:36pm] john3voltas: but i've tried on a virtualbox VM and sniffusb doesn't seem to work
[12:36pm] crope_: I use that tuner very often for live signals and from my experience its performance is not that bad. still maybe a little bit worse than latest e4000
[12:37pm] mchehab: if you can run it on KVM, you can sniff the USB on Linux
[12:37pm] mchehab: I wrote some scripts for that...
[12:37pm] mchehab: it is at contrib dir at v4l2-utils
[12:37pm] john3voltas: kvm? never used it
[12:37pm] mchehab: it is possible that it could also work with virtualbox...
[12:37pm] mchehab: if virtualbox is using the Linux USB stack
[12:37pm] john3voltas: it is
[12:38pm] john3voltas: i can actually see the dongle in the xp vm
[12:38pm] mchehab: so, you can sniff the traffic then
[12:39pm] john3voltas: well yea but apparently i don't have enough cpu to be running sniffusb AND the windows tuner software
[12:39pm] john3voltas: inside the VM
[12:39pm] john3voltas: mchehab: you wouldn't be Portuguese or Brasilian, would ya?
[12:39pm] mchehab: vm performance sucks for DVB, but still you may be able to get the logs
[12:39pm] mchehab: Brazilian
[12:39pm] john3voltas: legal
[12:39pm] john3voltas: i'm portuguese
[12:39pm] john3voltas: ok
[12:39pm] mchehab: nice
[12:40pm] john3voltas: if you say that i can try it even without image
[12:40pm] john3voltas: then i can try to sniff
[12:40pm] mchehab: we used to have one Portuguese contributor on V4L2
[12:41pm] mchehab: yes, the tuner setup occurs before the streaming...
[12:41pm] mchehab: so, on most cases, you can get the proper logs
[12:41pm] john3voltas: do you think i can sniff it and send it to you guys to take a look?
[12:41pm] mchehab: even when there's no image
[12:42pm] john3voltas: because i can't understand anything it outputs
[12:42pm] _abbenormal left the chat room. (Ping timeout: 240 seconds)
[12:42pm] mchehab: well, if you use my scripts, its output is basically the stuff written to r820t
[12:42pm] mchehab: you can even compare it with the stuff written on Linux and see what's different
[12:43pm] mchehab: I won't have much available time to dig into it on November...
[12:43pm] crope_: it is a little bit hard to look sniffs... I used scripts to generate C-code for r820t driver when I find out bug it didint worked for r828d tuner (this week)
[12:43pm] mchehab: as we are about to open a merge window
[12:43pm] mchehab: crope_: feel free to add those scripts to contrib at v4l-utils
[12:44pm] mchehab: we have there similar scripts for em28xx, for example, that also generates a C-like code
[12:45pm] crope_: yeah, we could do better job to release those scripts... but time is always short. I think there is tons of these scripts for every developer hard disk
[12:45pm] john3voltas: well unfortunately i know nothing about scripting. which means that i most probably won't be able to understand it without some help
[12:45pm] crope_: john3voltas: here is script you will need http://blog.palosaari.fi/2013/07/generating-rtl2832u-driver-code.html
[12:46pm] john3voltas: for now i'll focus on getting the sniffs to a file
[12:46pm] mchehab: crope_: the ones I use I generally add there at contrib
[12:46pm] crope_: john3voltas: but it eats SniffUSB format. so you will basically need one script to convert your sniff first to "parser.pl" format
[12:46pm] john3voltas: wow
[12:47pm] john3voltas: guys i am a linux noob
[12:47pm] john3voltas: i'll read it
[12:47pm] john3voltas: will do my best to understand it
[12:47pm] john3voltas: but in the end i will probably cry for your help
[12:48pm] mchehab: http://git.linuxtv.org/v4l-utils.git/blob/HEAD:/contrib/parse-sniffusb2.pl should do that trick
[12:48pm] mchehab: hmm... it does the reverse
[12:49pm] john3voltas: boss is calling me. nice chatting with you guys. if you want to tell me something after i'm gone, go ahead and write it. i always look at the channel's logs
[12:49pm] john3voltas: thanks a bunch
[12:49pm] john3voltas: c ya
[12:49pm] john3voltas left the chat room.
[12:49pm] crope_: here is simple patch, just for that r820t tuner, where I have used code generated by sctipts to find out bug http://palosaari.fi/linux/v4l-dvb/rtl2832p_dvbt_hack.patch
[12:51pm] crope_: it is usually quite trivial task to find out problematic registers using that technique - when you have starting point where linux driver does not work, but windows driver works
[12:51pm] mchehab: crope_: john3voltas left the chat
[12:52pm] awalls: ls
[12:53pm] awalls: oops, wrong window
[12:54pm] _abbenormal joined the chat room.
[1:15pm] crope_: mchehab: btw. as I added that RTL2832P + R828D support, I noticed R820T has likely big problems with power consumption (it does not seems to go sleep properly)
[1:15pm] mchehab: yes, I saw your patches. They look sane to me
[1:17pm] crope_: I deleted those power measurements, but IIR it was mayne even near ~200mA when idle. but I could look that issue later... I should take one weekend and try to fix those USB power management bugs .... there is very much. what I have measured it is very rare that dvb usb has working power management (only some of those newers likely what I have implemented)
[1:19pm] crope_: merbanan: noticed I added basic support for RTL2832P + R828D?
[1:20pm] devinheitmueller: crope_: would take much longer than a weekend to fix those problems - they are all over the codebase (tuners, demods, video decoders, etc)
[1:21pm] devinheitmueller: Power down the bridge and in many drivers the state of the driver gets out of sync with the state of the actual chip.
[1:22pm] devinheitmueller: …many drivers take shortcuts such as "don't change the modulation if it's already set to what the driver thinks is the current value".
[1:22pm] devinheitmueller: Enable power management in the bridge and you'll expose all sorts of bugs in the other drivers.
[1:23pm] crope_: devinheitmueller: yeah but there is even simple bugs that software sleeps are not working properly. I mean the I2C command send to chip that put chip sleep / standby
[1:24pm] devinheitmueller: Using a chip level sleep call typically exposes cases where the driver fails to wake the chip back up for all the possible entry points.
[1:24pm] devinheitmueller: It's similar to issues with i2c gates - you have to be careful to ensure every code path actually opens/closes the gate.
[1:24pm] crope_: GPIO based RST PIN sleeps are other issue as it resets whole chip. that should be implemented like those embedded guys did - using clock framework, GPIO framework and regulator framework, in order to define standard interfaces
[1:25pm] devinheitmueller: Good luck doing that reliably.
[1:25pm] crope_: :S
[1:25pm] devinheitmueller: That said, I do believe the drivers should be informed when something external yanks the reset line, so at least the driver has an opportunity to reset its internal state.
[1:25pm] crope_: current em28xx clock is maybe the first try and there has been that a lot problems...
[1:26pm] devinheitmueller: Imagine my surprise.
[1:28pm] crope_: there is still some easy parts to start. those DVB only tuners are most easiest / safest place to start
[1:28pm] devinheitmueller: Almost certainly. Not having to worry about hybrid devices with analog reduces complexity enormously.
[1:45pm] mrec: empia is dead anyway I wonder if they still have any hybrid market share
[1:48pm] mrec: their boss is about to retire (or mentally already retired) they only live from the cash they made in the past now
[1:48pm] mrec: until they're completely gone
[1:49pm] crope_: did empia made some other that pctv bridges / reference designs?
[1:49pm] mrec: they stopped
[1:49pm] mrec: no customers in that area
[1:49pm] mrec: pctv market crashed for them as well
[1:50pm] mrec: just see hauppauge, pctv systems, terratec they're all kind of down now
[1:50pm] mrec: the main thing they do is cameras now but that barelly can stand the current cost they have
[1:55pm] mrec: http://sundtek.de/images/pcb_640.jpg
[1:55pm] mrec: next hybrid cards
[1:56pm] crope_: for analog tv?
[1:56pm] mrec: DVB-C/T/T2/FM/Composite/S-Video (DAB+/FM HD is also upcoming)
[1:56pm] mrec: as well as DVB-C2
[1:57pm] mrec: AnalogTV of course
[1:57pm] crope_: selling to africa those devices I think
[1:57pm] wgreenhouse left the chat room. (Ping timeout: 240 seconds)
[2:00pm] mrec: dual dvb-c/T/t2 stick will be interesting
[2:00pm] mrec: R&D is currently working on it
[2:01pm] mrec: much nicer to do those things directly in Berlin nowadays
[2:04pm] crope_: usb-bub + 2 bridges?
[2:05pm] mrec: single bridge
[2:06pm] mrec: we're evaluating to put on some small fpga to lower the bandwidth as well
[2:08pm] crope_: how did you think fpga lowers bw? custom pid filtering
[2:09pm] crope_: and fpga is still quite expensive, eats power too
[2:11pm] mrec: several companies are using FPGAs nowadays for their designs.
[2:12pm] crope_: one fpga has a price more than cheapest 3-in-1 usb dtv chip
[2:12pm] mrec: well I'm gone.
[2:12pm] crope_: yeah, surely, if you has volume less than 100 000 000 pieces it is cheaper to use fpga than asic
[2:12pm] mrec: not everyone is interested in selling devices for 10$ and trying to make money from 10$ devices.
[2:22pm] john3voltas joined the chat room.
[2:23pm] john3voltas: is mrnicelinuxtv missing?
[2:23pm] john3voltas: no logs since yesterday
[2:24pm] devinheitmueller: john3voltas: it crashes periodically and needs to be restarted manually.
[2:24pm] john3voltas: oh
[2:24pm] devinheitmueller: I typically bug mkrufky when I notice it's down.
[2:24pm] devinheitmueller: (and he logs in to linuxtv.org's server and restarts it)
[2:25pm] john3voltas: he's not online
[2:25pm] devinheitmueller: nope.
[2:26pm] devinheitmueller: john3voltas: I just pinged him via email to restart the loggers.
[2:26pm] john3voltas: thanks mate
[2:26pm] devinheitmueller: np
[2:27pm] john3voltas: unfortunately i was trying to read a chat from earlier today with crope and mchehab and this way it will be impossible
Comments
Post a Comment