Log in Register FAQ Memberlist Search pcHDTV Forum Index
pcHDTV Forum

pcHDTV Forum Index -> HD-2000/3000 drivers -> Linux 2.6.2 driver available. Goto page 1, 2, 3, 4  Next
Post new topic  This topic is locked: you cannot edit posts or make replies. View previous topic :: View next topic 
Linux 2.6.2 driver available.
PostPosted: Tue Jan 27, 2004 7:41 pm Reply with quote
Joined: 06 Nov 2003
Posts: 95
Location: Aptos,CA,USA

I took the last version of my patch (draft_3n) and tried to separate it from all other drivers. I had trouble getting it to isolate from other drivers. I named the module version of it btatsc (I haven't tested non-module version, but I have no feeling that it shouldn't work except perhaps some compile errors), and put the source code under drivers/media/dvb/bt8xx (as atsc/) hoping to eventually do something more integrated with that area, but for now it's just a copy of what I had before (messiness preserved). This is very very untested; I haven't tested the case of loading bttv pure module, or having another type of bt card in the system, etc. I was able to tune & get MPEG TS files out of it, so it seems to be working.


Kernel 2.6.5-rc3 doesn't let nvidia 4465 driver load, so I couldn't test mplayer with that. There are very few patches in drivers/media/video left with the below; just some tuner.c updates and unique things I have, and a few other tiny things with mode stuff I created. CONFIG_DVB_BTATSC (the renamed config entry) wasn't being set during some compiles of includes, so I just got paranoid and set it in front of every single file; someone could tell me what went wrong. (It wasn't getting definition for dev2 in struct btatsc, I think.)

I commented something similar to what joev commented, and I hope that helps a few systems; it would need to be fixed in order to get NTSC to work, though, but since NTSC wasn't working anyway, I thought it was OK for now.

Ok, nvidia (4496 version patched to work with 2.6 kernels) does work in 2.6.4, but not 2.6.5-rc3. btatsc module works in 2.6.4 (tested with mplayer). TS file created above with 2.6.5-rc3 worked, too, in mplayer. Everything seems OK, with respect to minimal function we had before with my patch (still lots of problems, probably). Have fun.


stevew wrote:
I moved the buffer_alloc call to the dtv_init call, so the buffer is allocated when the driver loads.

Similar change added to draft_3n, along with previous 3n buffer size modifications (mentioned below), and some C formatting style changes and printk changes to start to adhere changes to standards (but no additional debugging code). Patch diff from linux-2.6.4-rc1.



diff_draft_3n_in_progress.diff is not yet a full release, since the change is so simple and unnecessary for those who don't need more buffer, but stevew told me how to do this correctly. I guess not reading the code made it hard for me. Anyway, it works, and you can now just change the define in one place, and it will update everywhere else. Find it in the same directory as the other patches.


Really weird! draft_3l doesn't work for me, but draft_3m does! Only revert buffer size. Doesn't make any sense. I couldn't increase my buffer size.


draft_3l (that is an L) out with stevew inspired changes to m10_schedule (but taken from e1000 & tulip); followed his lead on buffer size change. Strange! draft_3l doesn't work in linux-2.6.3-rc4! draft_3k does. Basically identical to before, so query below still applies:


draft_3k out. Has a few fixes to the new unfinished stuff in an effort to get NTSC to work. Didn't succeed. However, I am amazed at how much closer I am to doing what I want by just modifying what I already did so far. Did partial link test, and tested DTV & it works. Does ANYBODY have v4l NTSC HD-2000 device working in 2.6?


Well, I'm still not going to finish it (see below), but at least I threw together a compilable version of the latest stuff with draft_3j -- I tamed my adventurous stuff that's only half done and got it to stay out of the way enough to at least output DTV. I couldn't get NTSC to run right. Sorry. I'm not going to work on that right now. dtvsignal works fine, still. The main thing I did which is better than draft_3g is finally put jiffy HZ support in; I still think it's legacy code, though, since I ought to research if "udelay()" does schedule(). Anyway, I put the delays for signal back to where they were (apparently, I found much lower delays that worked in my system for the previous version).


****** [some ****** seperators in this message may be in wrong place]

This time use "patch -p1". It was tested with linux-2.6.3-rc2. FWIW, the other version #s I have:

* media-video/mplayer
Latest version installed: 1.0_pre3

& I use my version of dtvsignal; I put it in the above FTP site, too. Everything is still also at ftp.armory.com, too.


I can't finish this, since I have to get some income. My most recent project was V4L2 IOCTL support, including accessing any capability from any device node. It would take me about two weeks to finish that, so I can't do it now. I'm not sure how useful it would be, since applications would need to know how to handle the output of those. I'm going to leave draft_3h & draft_3i in FTP, but since I haven't even finished understanding it, I know it won't work. I wanted to finish the above just to leave it V4L2 compatible, then get a DVB frontend driver (there are already 3 that use bt like that, I think), so that programs can use DVB drivers for pcHDTV. I won't be doing that until I get income, so I doubt I'll be the one to do it.


Assuming linux-2.6.2-rc3 is similar enough to 2.6.2, I have a working patch for 2.6.2:


Unless otherwise noted, all patches are cumulative; only one needs to be applied to a pure linux-2.6.2-rc3 or similar source tree. (If you had a previous patch, just either reverse it first, or make an extra pure tree including only drivers/media/video and include/linux, patch it with the new patch, and then diff patch or copy (bttv-*.[ch] tuner.c) the results to your old tree.)

draft_3g fixes old v4l1 struct video_channel.flags hack for setting second input. Evidence shows this wasn't working the whole time for linux-2.6. I'm surprised I didn't see it sooner! It has to do with the order in which I approached these mini-projects. I also changed a bit of stuff to act differently in VIDIOCSCHAN v4l1 call to act more like v4l2 calls; tell me if it's buggy. I tested setting input using both old and new methods, and now it works. During this event, I put some debugging lines in the driver. This all happened when I decided to add second input support to Koreth's tssave utility. I found his utility in the process of saving all the forums in preparation for culling them.

You'll find a test_v4l_ioctl program; I keep updating it. It's just for me to test with, but I figured I'd leave it there for others. It is definitely not finished; I spent a few hours putting V4L2 data in it, so I'm also preparing to do that too.

Neither culling or V4L2 is finished.


draft_3f re-fixes kernel build & link test for what should be all six possible .config options (since normviachan option installed; see pontification below for original description of idea). I'll test this again completely before a non-draft release. I believe draft_3f is ready for alpha testing, but it won't be a non-draft path, since I have other things to do, too. I have not crashed my computer with this driver (nor I think with any of the below patch sets). [The only time my computer crashes is sometimes while switching between X and non-X windows while running the latest NVIDIA driver which supports linux 2.6. I think this is a known bug. I think it is not related to my patches, since I can't see how they would be. I'd prefer they get a stable version of their driver supporting 2.6, but I haven't tried the older more stable NVIDIA driver with 2.6 build hacks.]


draft_3e added preliminary v4l2 signal support. It's untested; I doubt it won't work. v4l2 API support still not finished.


draft_3d fixes signal strength! Wow, it's cool to actually see it work correctly for the first time. Details:
* draft_3d restores binary and API compatability with old dtv tools for signal strength that I took away in draft_3b;
* old utilities now work correctly! Two main points:
A. No jitters. Had to increase jiffie waits in getsignalstrength routine. It wasn't getting correct data from the card (they were arriving out of order, out of sync, etc.; perhaps still a bug in I2C interaction? If so, please tell me how to fix.) During diagnosis, I found out how to detect the bug in action, and it auto-corrects most instances of it (a few where data == command bytes will get through, but that's really not a big problem for now; I haven't even seen that yet, and now that jiffies are better, it probably will almost never do that).
B. The second field (pre equalizer signal strength) now works. All three of my channels show different pre-equalizer values, but similar post-equalizer values:

These are stable readings: notice how the second value (SNR pre equalizer) stabilizes to diverse values, whereas the first value (SNR post equalizer) doesn't:
channel = 10 freq*16 = 3092
Signal:           |    .    :    .    |    .____:____.____|
Signal: 092 (051) ##############################

channel = 12 freq*16 = 3284
Signal:           |    .    :    .    |    .____:____.____|
Signal: 087 (-26) #############################

channel = 13 freq*16 = 3380
Signal:           |    .    :    .    |    .____:____.____|
Signal: 090 (062) ##############################

Isn't that cool?

BTW, the bug for pre-equalizer data was totally simple: they were taking [2] instead of [4] of a data array. (This bug is also present in 2.4.24 version of driver: *aux =((int)rec_buf[2])&0xff; change 2 to 4 (so ....rec_buf[4].....). Someone can correct me if I'm wrong. I don't think this value ranges from 0 to 0xCB like the other one.)

draft_3d uses the same byte order data for the above, however, I made a new struct that doesn't do wacky type conversion (expecting signed integers to behave like unsigned chars, etc.; a sample of that old behavoir is above in the 2.4.24 patch correct); the new variables are snr_uneq and snr_eq (temporarily I had them named snr_bef_eq and snr_aft_eq, but I think the new names are more proper; someone can correct me.)

V4L signal (via VIDIOCGTUNER) now works; special VIDIOCGSIGNAL ioctl no longer necessary for basic V4L functionality.

I'm going to work on V4L2 later. I was just doing V4L first, since now I will actually know what I'm doing when I start working with V4L2, and I know where the driver came from.


draft_3c is actually when I did most of the above, but it had a dumb bug which I fixed, so I edited this message to refer to draft_3d.



draft_3b is out. I'm being more bold, changing more things, doing generally more dangerous stuff. This is more development oriented than some of the below, but since I've been working more on it, it has a few slightly more interesting things, and what has been done is more finished even though there's more of it (and more ways to fail). It is only half tested. MythTV, between a load of crashes, actually recorded a whole hour of my favorite show off of the HD-2000 card, so it isn't totally broken. I'm understanding more as I work with it more. Here are some of the things I am hacking into it:

* Better V4L and V4L2 bttv API support. I am only testing capabilities right now; I'm writing a little tool to query it.
* I fixed V4L signal strength reading, and broke dtvsignal signal strength reading. dtvscan won't compile. I need to go, so I can't figure that out right now.
* Jittery signal strength was fixed with two items: increase jiffies waiting, and a few checks with loops to retry if it fails the first time. If jiffies were the problem with signal strength, I wonder if jiffies will be a problem in many other places, too. Someone with good kernel jiffie knowledge should explain this to me. I generally know what a jiffie is; I need to know specifically what changed since 2.4 that cause us to have to increase them. It clearly might not be a jiffie issue, but jiffie delay increasing helps, or it may be a jiffie issue.
* I think setting norm and channel is easier now; I've been working mostly on that for the last few days. I have a lot more testing to do; don't expect it to work, but if it does, that's great; I haven't confirmed that it doesn't work, so this may be the case. I'm changing some of the code to do bitwise work, which I'm good at (probably a lot of people are), so I have high confidence in it.
* I want to finish checking the V4L API, then fix everything I broke (e.g., dtvsignal), then try the new features I put in (normviachan, and selecting 2nd inputs, etc., e.g., in MythTV), then I will proceed to the following:

* V4L2 API programming and verification (it's mostly done, but I want to check it);
* Culling patches from this forum (yes, I wil get to it);
* and finally, after trying to half-polish this as a release for the V4L/V4L2 bttv arena, attempt to make a DVB interface for this card like the other three drivers that use bttv as their backend driver.

Framebuffer reading is probably still going to be broken, since I don't understand it yet. As I've thought about this more, I think it should still work as well as it ever did.


For those using linux-2.6.2-rc2, I made a patch from that to rc3; I recommend you use it, since it doesn't have any of the changes which would conflict if you tried to do reverse to 2.6.1 then forward to 2.6.1-rc3 (or you could duplicate it yourself easily enough):
(no longer at FTP site)


I hadn't tested 2.6.2-rc3 yet for drafts below, but since, have had no trouble with it, working on most recent below and all above; it has some PCI stuff in it. I'm going to use V4L2 API to slowly test all the V4L2 functions of bttv HD-2000 driver, and then the V4L API. So far, just sort of looking at stuff, I made a few minor changes already that correct some API problems, but since it was already working before, I have no idea whether they'll help. My more thorough approach may at least yield a bit of more correct behavoir, but like I said, it may not matter.

One idea I am thinking of [implemented in draft_3* above with normviachan option] after that is making a module option which allows you to tell it to add two more inputs which correspond to NTSC versions of the two existant inputs; that way, for instance, in MythTV, you would have four (4) channel lists for the same card, and it would just happily set the input ("channel" in V4L & V4L2) to one of those according to which channel list Myth wants (TV channel in MythTV?), and Myth wouldn't need to set mode, norm, or anything else! However, it WILL need to know what mode, norm, or whatever it would need to interface from after that point. Note that since Myth crashed for me tonight a typical dozen times in as many ways (through less than normal use), I actually never test it thoroughly, since I don't take it seriously. I prefer mplayer! Someday, I'll compile xine 0.7, too (another TODO project). Since Xine maintainers are hovering here a bit, perhaps later xines have HD? Never mind, another day ... for now, V4L2 & input to mode conversion option hack consideration. I'll put another patch tomorrow.

Fixed a problem where people with configurations expecting input text label "Television" won't have to reconfigure to "Television0" (such as in MythTV, etc.). If you already did reconfigure (as described below for draft_2b patch), you can either go back (fairly easy), or change "Television" to "Television0" in the code (but that's harder to maintain). Other "aux" input still has numeric suffix (i.e., "Television1"). A few other minor changes -- one cleanliness, another diagnostic, and another hopeful guess in progress. Nothing major.


This is a slightly cleaner version of what's below, but I'm more upset now since I found a lot of things that don't work when not in ATSC programs and modes.
Be careful not to set ATSC mode on non-pcHDTV cards; for all I know, it could blow out some HW.


Adds input selection via "input channel"; called "Television0" and "Television1" (requires reconfiguration, e.g., for MythTV, to mythconverg.capturecard.defaultinput & mythconverg.cardinput.inputname & restart mythbackend; for xawtv (which still doesn't work anyway) ~/.xawtv; see draft_2d which removes this requirement):


No real change from 2.6.0-2.6.1 patch:


also available at


The following works:

* New Kconfig entry. You must edit .config somehow to properly add CONFIG_VIDEO_BTATSC=y. It depends on CONFIG_EXPERIMENTAL=y. For "make menuconfig", the new option is at: Device Drivers: Multimedia devices: Video For Linux: Video For Linux: BT848 Video For Linux (which must be set to M or Y): pcHDTV HD-2000 (Y is only option). See mini-howto below.
* Tested above in all combinations of N N, Y N, Y Y, M N, M Y (respectively): it compiles and links cleanly in all cases, and in the case of Y Y and M Y the kernel will boot and the driver will load, and in the case of M Y I have successfully tested mplayer on one of my usual local channels for typical A/V.
* 2nd input port using my patched dtvsignal to support 2nd port via tuner mechanism works.

draft_2b, 2c, and 2d (use draft_2d):
* Put 2nd port selection via normal video input interface.


* More updated version of driver: this patch is based on a patch which was based on a patch which was based on a patch which is older than what is now available for linux 2.4. One attempt I made to make an updated patch available failed, however, I will refer to that attempt to try to update this patch. For now, it works.
I tried to go get this, but for some reason, it wasn't where I thought it was. I consider it "complete" with the method I used (which netted zero results), but if my method was wrong, i.e., there were updates, then PLEASE fix this (tell me or otherwise).

TODO and currently doesn't work:

* dtvsignal still jittery.

* xawtv in Linux 2.6 uses V4L2, and my xawtv input port patch did not go so far as to modify v4l2. That is to-do. Supposedly, if I successfully put 2nd port selection via normal video input interface, that won't be necessary.
* Cull these support forums for other patches and features, and apply them. Est. time of work start: Saturday or Sunday. BTW, I had no idea Football was this Sunday; sorry about the bad timing regarding that --- I stress in general that you don't overset your expectations for that day (i.e., do actual run-time test on that very soon before making commitments).

I intent to do all of that this week. Now, only one item left, so on schedule.


* While writing draft_2c, I did testing, and found out that xawtv and mplayer cannot access the device in NTSC mode. Here are some of the errors I am getting:

<<<<< are my marks of problems I see:
$  mplayer -tv input=0:channel=12:driver=v4l:device=/dev/video0 -zoom tv://

ioctl get tuner failed: Invalid argument <<<<<<
Tuner isn't capable to set norm!  <<<<<<
Error: Cannot set norm!

Exiting... (End of file)
ulmo@A:/usr/src/linux:48048$ Jan 30 01:17:25 A tuner: vc->norm $0; vc->flags $0, vc->channel $0
Jan 30 01:17:25 A bttv: Btatsc_Setmode Rec Status 20 03
Jan 30 01:17:25 A bttv0: IRQ lockup, cleared int mask [bits: OFLOW GPINT*] <<<<<<<<<<<

There are lots of other problems like that. v4l2 doesn't work. mmap fails. xawtv doesn't work.

I am confused here:

g NTSC /usr/src/linux/include/linux/videodev.h
#define VIDEO_TUNER_NTSC        2
        __u16 mode;                     /* PAL/NTSC/SECAM/OTHER */
#define VIDEO_MODE_NTSC         1

        /* p1: = VIDEO_MODE_PAL, VIDEO_MODE_NTSC, etc ... */

So, norm is 2 for tuner and 1 for video-driver, but:
$ mplayer -tv input=0:channel=12:driver=v4l:device=/dev/video0:norm=NTSC -zoom tv://
Inputs: 5
  0: Television0: tuner audio tv camera  (tuner:1, norm:ntsc)
  1: Television1: tuner audio tv camera  (tuner:1, norm:ntsc)
  2: Composite2: audio camera  (tuner:0, norm:ntsc)
  3: S-Video: audio camera  (tuner:0, norm:ntsc)
  4: Composite4: audio camera  (tuner:0, norm:ntsc)
Using input 'Television0'
ioctl get tuner failed: Invalid argument
Tuner isn't capable to set norm!
Error: Cannot set norm!

Exiting... (End of file)

Jan 30 01:38:51 A tuner: vc->norm $1; vc->flags $0, vc->channel $0
Jan 30 01:38:51 A tuner: tv 0x0e 0x30 0x8e 0x92
Jan 30 01:38:51 A bttv: Btatsc_Setmode Rec Status 20 03
Jan 30 01:38:51 A bttv0: IRQ lockup, cleared int mask [bits: OFLOW GPINT*]
Jan 30 01:39:00 A CRON[9529]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons )
Jan 30 01:39:00 A CRON[9531]: (ulmo) CMD (/bin/netstat -a < /dev/null >

mplayer should be using norm 2 for tuner setting, and 1 for v4l setting, right? I'm confused. Norm isn't right when it gets to tuner (it says 1 above, instead of 2).


There are also some maybe todo items:

TODO that I might get to this week, or might not:

* V4L2 compatability.

In addition, there are things that need doing that I will not do this week:

TODO that I won't do:

* Rewrite HD2000 support to fully support V4L2.

In addition, there are other features and modifications being discussed in these forums that no one has posted patches for; I will not be doing those things here.

My goal is simply to eventually (within a week?) make available to Linux kernel version 2.6.2 users everything that has been publically done so far; I do not have as a goal to go beyond that. Anybody with new driver rewrites, new features without patches already posted, or other major changes without patches already posted, will have to do those things, because I'm not. I am not stating here whether or not such things are needed.

Additional notes on my patch:

* I unilaterally decided to rename "bttv-drv.c" to "bttv-atsc.c". Another option, better in most ways, was "btatsc.c", but it did not fit the standard in the Makefile of all bttv-objs having "bttv-" prefix, so I followed that standard instead.
Anybody may protest this decision, change it, etc. I just was sick and tired of tabbing "bttv-dr" and getting stuck deciding between suffix "iver.c" and "v.c", and trying to remember to type "drv.c" instead of "dvr.c" (or whatever it was), and the name wasn't that descriptive. Just because I gave the file a nice name now doesn't mean anything else. Other better names could be "bttv-hd2000.c", "hd2000.c", "bttv-pchdtv.c", or better yet, the name of the chip that HD-2000 is based on (whatever that is) dot c, perhaps prefixed by "bttv-"; someone who actually works with the code can tell us a good name for exactly what that file interacts with (some Philips thing?). Yeah, I'm being lazy right now; I could look it up, I guess. Inertia already had "btatsc" in all the function names and printk's in that file, so I used that as my baseline for the name.

* I #ifdefed everything I could to seperate stable release code from unstable code. I marked the ifdef "EXPERIMENTAL" in Kconfig. I put in a few error messages that get printed if you try to load this card without CONFIG_VIDEO_BTATSC=y; they tell you to turn that on, so if you see the errors in syslog, you'll know what to do.

* Some more unilateral decisions; subject to comments and acceptance:
+ Renamed "svhs" to "svideo"; this changes a module option in bttv.
+ Renamed "Television" to "Television_Tuner", "Television_Audio", "Television", or "Television0" depending on meaning (tuner, audio, television --- oops, uhoh, ok, I just realized a bug --- will make a draft_2c that fixes this since it's just cosmetic for now (naming) -- anyway, television with suffix depending on ATSC card -- I'll reprogram to make it only do "Television0" for HD-2000 for draft_2c).
* Can query and select RF Input via either mechanism of the old flags bit or the second Television input channel. Right now, for HD-2000 cards, it is named "Television0" and "Television1" for the two inputs. (Unfortunately, all bttv cards compiled with these options will have a "Television0" no matter what; what I'll fix in draft_2c is that only dtv cards will have a "Television0", and the rest will just have "Television".) The two values are OR'd; if you get an application to set at least one of these to the 2nd input, the driver will select the 2nd input; to get the first input, you have to set both input channel and flags&0x100 to 0. This isn't hard, since if you can set both to 1, then you can set both to 0. Most programs do not support flags&0x100 function anyway, so I do not have a large concern here. Programs that use flags&0x100 include HD-2000 CD tools and my tools patched to handle this second input; programs that use input channel selection are mplayer, MythTV, xawtv, etc.

One patch I have not culled yet is the one that automatically sets other data according to which input (or other attribute) is selected. That's this weekend's task, but I only promise to look at it (not necessarily like it enough to add it, but I think I'll #ifdef it or something).


Mini Howto

I'm going to try to slowly edit this message until I have a pretty full mini-howto about how to get everything working with the patches I will be posting here.

* pcHDTV HD-2000 card. See the written instructions that came with your card. Anything here that conflicts with those instructions, figure out which one is best; this probably has new information, so try this first, but then see what you can learn by reading those written instructions.

* Get Linux 2.6 kernel compatible with above patch; this may be just linux-2.6.2-rc2 and fail with 2.6.2 proper, or it could work for many more kernel releases; we will not know until it happens. First, consider how you want to get your new kernel. You can follow your Linux distribution instructions on how to get a new kernel, or you can do it yourself. At some point, you will have to make the two compatible (your work and the distribution's work). This is a decision that is outside the scope of this minihowto; see many other kernel patching and building instructions for that. If you want a pure kernel, get it from a mirror of ftp://ftp.kernel.org/pub/linux/kernel/v2.6/; check the file "LATEST*" in that directory for latest kernel. Always get and verify signatures (I do, even if I find a file I need already laying around someplace on my disk); install and learn package GnuPG to do that (e.g., "gpg --verify foo.sig" or "... foo.asc"). Find kernel buildng instructions in some other howto, but don't start building yet.

* Refer to what documentation you have from previous step to get kernel source unpacked (e.g., for pure, "[ -d /usr/src/linux-2.6.2 ] || tar jxCf /usr/src/ linux-2.6.2.tar.bz2 "). This may entail applying patches (e.g., for pure, "[ -d /usr/src/linux-2.6.1 ] || bzip2 -dc patch-2.6.2-rc2.bz2 | patch -p1 -d /usr/src/linux-2.6.1"). Switch to that directory. E.g., if /usr/src/linux is a symlink to /usr/src/linux-2.6.2 ("rm /usr/src/linux; ln -s linux-2.6.2 /usr/src/linux"), then "cd /usr/src/linux". Before you get excited, figure out whether it's safer to finish doing other configuration first (copying previous .config and .version files, applying already in-use patches to fresh trees, etc.) before you forget to. Make sure you're in the right place ("head Makefile" should show proper version # to Linux kernel). Apply the hd-2000 patch (e.g., "bzip2 -dc diff_draft_1d.bz2 | patch -p1).

* For pcHDTV HD-2000, the following configs are minimum (this list may not be complete while this mini howto is being written; people may tell me what I forgot): "m" is less than "y" ("m" means "y" will also work if available), and if I didn't specify, that's because I don't know what's minimum, so try both (y is safe).


* Install kernel according to other documentation that tells you how (e.g., "make; sudo make modules_install; sudo make install" or something; I find it's best to write a shell script which does the various stages of this for you, so that you can type one command, and after it's done, your system is ready to boot with all accessory software modules, etc. ready to go; my current script for 2.4 compiles the kernel, does make modules_install, makes a record of .config, .version, System.map, vmlinuz & puts them all into appropriate locations, prepares them for botting, and then ALSA, lirc, IVTV, links NVIDIA, and at least a few other things I'm forgetting right now, and runs depmod; it fails if something doesn't work, and otherwise it succeeds. It has to use Makefile and some version header file in the kernel tree to properly set build directories, linker maps, header files, module targets, etc. for other packages as they compile; sometimes this doesn't work and I just re-run the script again when I boot into the kernel (half of them will allow you to compile without the target kernel running, but you have to learn the options for each one). This script applies all relevent patches, etc., that I want on everything included in above. If it has a successful exit value, the system is ready for reboot.). Make sure this new kernel is running (i.e., reboot ("sync;telinit 6;sync;logout").
* Make sure /dev/video* is correct ("ls -l /dev/video32", and if it is not correct, "sudo mknod -m 600 /dev/video32 c 81 32; sudo groupadd vin; sudo chgrp vin /dev/video32; sudo chmod 660 /dev/video32" or similar. I use "video" for group, but should seperate input & output into "vin" and "vout", so I put the better example.). Make a simlink to dtv since a lot of utils like that ("sudo ln -s video32 /dev/dtv; sudo ln -s video32 /dev/dtv0").
* Get foo at foo (ftp.armory.com/pub/users/ulmo/hd2000/tools/.../tools.tar.bz2), and build and install that. Learn how to use "dtvsignal". Tune your antenna. Learn what input goes to what. Use ATSC channels. Use http://something.proximal. something.antenna. something. finder. com, http://www.fcc.gov/ ... foo, and/or http://www.TitanTV.Com/ ... to find them. Look for callsign suffixes DT, DS, HD, SD, and others; I think FCC standard has a dash in there (e.g., KCBA-DT). Places such as TitanTV and Zap2It often use keyword "HDTV". The standard is called "ATSC", and is used computer programs here and there. Once you have found one station, or even if you cannot and want to try something else, learn how to use dtvscan, and eventually after having fun with that, save a collection of its best output (stdout) into ~/.xine/chanlist ("mkdir $HOME/.xine; dtvscan /dev/video32 >> $HOME/.xine/chanlist"). I think xine might use it, although it certainly isn't necessary for it to work. However, since that's where xine wants it, that's where I keep it. I mostly use it, however, as a reference myself. I edit it to make it a good resource. I collect the best runs of dtvscan I ever got for every channel and put them it into that file. I make backups of it. I refer to it whenever I need data. The most important items in there are the many different values for channel and program, and the callsigns. These are different everywhere, so I need a good reference which I relate everything to, and this is it. Another one you could use are notes you create after carefully using FCC data. If I were comprehensive, I would add comments to the above file with all FCC data I got. Someplace I have a handwritten table of FCC data showing effective radiation from their site to me, direction, etc. It takes a while to get accurate values for this. (Careful: there are multiple Latitude & Longitude standards, and FCC & topo map data use some from both).
* Get xine from this web site outside of these talk forums (home page has link for Downloads at http://www.pcHDTV.Com/...foo...foo).
Buld & install that.


* foo something else except that mess below listed first.
* You could set up shell scripts that run with "atd" (with a terminating "kill" or "killall" or "fuser -kv /dev/video32", or just start with "fuser -kv /dev/video32", re-init (sleep 1))), which then use "dd if=/dev/video32 bs=32k | bfr -b16m | dd of=somefile bs=8k" , or something similar (like "getatsc", etc.). Then watch using xine-hd or find a transcoder that can read those streams ("mencoder" from "mplayer" package?).
* http://WWW.MythTV.Org
There is a good HOWTO about a baseline installation at that site. First and afterwards see MythTV forum in this forum. It has discussions which will tell you most of what you need to know, including extra steps necessary to get XMLTV to get (incomplete) listings for your area (there are at least two ways to do this), editing channel tables to get it to do that, and patches to apply to MythTV to get it to work a bit better with your setup. I have found MythTV to be unreliable, however, that is mostly because I have a mixed system that also has an IVTV driver based card in it; occasionally, Myth will successfully record ATSC streams just fine, and mostly it fails because it gets mad whenever ivtv doesn't work and just totally goes on strike, so I think its HD-2000 support by itself is sometimes fine. It still takes some work to get it to run well with other cards. At this time, Myth 0.13 is release level and CVS has some good stuff, so install the most recent stable release using HOWTO documentation and then upgrade to CVS right away if it has anything you need, if you're willing to fight the dev list (it's full of nice people and otherwise, being partially terrorized by some power hungry idiots).

not complete.

Last edited by Ulmo on Wed Mar 31, 2004 12:26 pm; edited 34 times in total
View user's profile Send private message Send e-mail
Re: Linux 2.6.2 driver available.
PostPosted: Tue Jan 27, 2004 10:36 pm Reply with quote
Joined: 11 Nov 2003
Posts: 55
Location: Albuquerque, NM

Ulmo wrote:
Assuming linux-2.6.2-rc2 is similar enough to 2.6.2, I have a working patch for 2.6.2

Excellent Exclamation I should get home Thursday night and can't wait to try this.

TODO and currently doesn't work:

* dtvsignal still jittery.

Do you have any ideas for the cause of this problem? Jack is suppose to be working on an "offical" patch, but it has yet to materialize. I wonder if he is having trouble with this....

TODO that I won't do:

* Rewrite HD2000 support to fully support V4L2.

It would be nice if this is what Jack is working on, and the reason for the delay Smile

Since Jack's "official" driver is vaporware, I am thankful that you have continued to work on this.

View user's profile Send private message Send e-mail
PostPosted: Wed Jan 28, 2004 10:40 am Reply with quote
Joined: 15 Jan 2004
Posts: 22

From the description, there's been some significant cleanup since the last 2.6 driver, but functionally it's not much different. From a user's perspective, is there any advantage to this driver over the previous one, other than that it allows me to upgrade from 2.6.1 to 2.6.2?
View user's profile Send private message
PostPosted: Wed Jan 28, 2004 12:37 pm Reply with quote
Joined: 06 Nov 2003
Posts: 95
Location: Aptos,CA,USA

crow wrote:
From the description, there's been some significant cleanup since the last 2.6 driver, but functionally it's not much different.

I think that was correct when you wrote your message and I first answered it (wrt draft_1d), probably without the word "significantly".

From a user's perspective, is there any advantage to this driver over the previous one, other than that it allows me to upgrade from 2.6.1 to 2.6.2?

When you wrote your message, no (draft_1d). I said I will resume work on it Wednesday night & Thursday, and then there might be some mildly interesting stuff. I finally got to it today, and just completed draft_2b this evening (Thursday).

The two main reasons I put the patch out there so soon are:

* 2.6.2 is coming fast, and it's just easier to have a patch available even if there are no effective changes;
* Those who are already attempting to use 2.6.2-rc2 (release candidate 2) will be in a position to find any bugs in the patch, so that when others actually want to start using current stable release, we'll have had a chance to figure out how to fix it.


The next thing I said I will work on will be one of:

* cull modifications from forums (I saw a few, but have to find them); not done as of Thursday draft_2b;
* attempt to forward-port this patch to the newer version already available for 2.4 (and part of why I did my last failed attempt with bttv-0.9.12 driver); not found when I tried to do this as next project today (so nothing from this in draft_2b regarding this);
* try to re-program 2nd tuner rf input via normal bttv card capabilities. I have decided to not use new "tuneraux" capability like in my most recent 2.4.24 patch which does that (and started to re-do in draft_2_halfdone); instead, I will try to special-case the code for this card everywhere where tuners are referred to; now, that's mostly the way I did it for draft_2b; I think I'll do a sort of cleaner version for draft_2c.

When first posted, I was trying to decide which one to do first, and said: Trying to get updates from the new version in 2.4 seems like the most important because it just seems so tedious but important to just get out of the way, but then it could take a very long time, so it may be more useful to do one of the other tasks first. I think I'll only do about one of those items per couple of days. Of course, someone else could too. If someone is waiting for one particular thing, I could start with that.

Now, you can see draft_2b has chosen input selection and failed an attempt at patch version update.

If no one posts any new messages to this topic by about Friday afternoon, I will, to trigger tracking and notification for edited messages above.
View user's profile Send private message Send e-mail
PostPosted: Sat Jan 31, 2004 2:19 am Reply with quote
Joined: 06 Nov 2003
Posts: 95
Location: Aptos,CA,USA

Ulmo wrote:
If no one posts any new messages to this topic by about Friday afternoon, I will, to trigger tracking and notification for edited messages above.

Here is a new message. I was slow because I didn't think my updates were that wonderful, but someone may actually want the input patch (the only nice new thing for now). In half an hour or so, I will probably post a draft of V4L & V4L2 work, but that is more draft (only about two of about twenty or so changes that will probably be neded); check the FTP directory, since I probably won't feel it's worth mentioning here since it will be too untested.


Well, I'm mad. In V4L API:
The flags defined are

VIDEO_VC_TUNER Channel has tuners.
VIDEO_VC_AUDIO Channel has audio.
VIDEO_VC_NORM Channel has norm setting.

In V4L2 API:
6. History
6.1. Differences between V4L and V4L2
6.1.3. Video Sources
The norm field describing the supported video standards was replaced by std. The V4L specification mentions a flag VIDEO_VC_NORM indicating whether the standard can be changed. This flag was a later addition together with the norm field and has been removed in the meantime. V4L2 has a similar, albeit more comprehensive approach to video standards, see Section 1.7 for more information.

Well, my compile with VIDEO_VC_NORM flag failed because it's not defined! This guarantees I will be adding an option to V4L bttv HD2000 support to have four total tuner inputs of both modes and both inputs (4=2*2), since otherwise, there's no notice to programs via API that it does support multiple modes.

Then, I'll try to get V4L2 to work right. I'm at a point where I have confidence I can do API updates, but not HW interaction updates. I'm paranoid to change the order in which HW is accessed or how it is accessed, even though there are some glaring duplications and misplaced code in interaction between bttv-driver.c and bttv-atsc.c.

edit 2:

Oh I see: we're not supposed to be using V4L or V4L2:

I. Function Reference
[a totally stupid API which has you do one system call for every supported standard to find out what works, even though the standards are defined in a bitmap, which could be returned with only a single memory access, and as part of another general call!!!]

V4L2_STD_ATSC_8_VSB and V4L2_STD_ATSC_16_VSB are the U.S. terrestrial [sic] digital TV standards. The present V4L2 API makes no provisions for digital TV reception, so no driver will report these standards yet. See also the Linux DVB API at http://linuxtv.org.

(I have a terrestrial service: cable; "terrestrial" is how I differentiate it being NOT ATSC, so for me to see someone say "ATSC is terrestrial" is to see garbage; my ATSC reception is nonterrestrial; it's air, and I call it that. Perhaps they mean near terrestrial, as opposed to satellite. They must be space aliens.)

Anyway, I'm now looking at DVB API to see if it supports ATSC. If it doesn't, then there is NO Linux API to support ATSC, and we might as well just create /usr/src/linux/drivers/media/atsc and put our very own drivers and home-made API there.

There's already an interface to bt878a DVB boards via the bttv driver discussed at /usr/src/linux/Documentation/dvb/bt8xx.txt. I think we might want to follow this model if DVB supports ATSC.
View user's profile Send private message Send e-mail
Don't have a cow man
PostPosted: Sun Feb 01, 2004 7:37 am Reply with quote

The document you quoted is right. It is really all just a matter of semantics.

ATSC is the standard for encoding a video signal. It replaces the old NTSC standard

There are then three types of transport methods that are universally accepted.

refers to OTA (Over the air) signals. In europe this is called DVB-T. Terrestrial signals in the US are modulated using 8VSB (vestigial side band) There is also 16VSB which would allow for sending more data through the same channel but it isnt really used anywhere

refers to cable signals(obviously) it is refered to as DVB-C in Europe. Us Digital Cable is modulated using QAM(Quadrature Amplitude Modulation).

refers to satellite signals. It is refered to as DVB-S in Europe. US Digital Satellite is modulated using QSPK(Q-phased shift key).

Now, no matter which your using they are all carrying an ATSC signal. They are just modulated differently for transmittion.

As for DVB supporting ATSC the short answer is yes but the long answer is no.
ATSC is simply an extention of the mpeg transport stream protocal which is also used by DVB so there should be some overlap but since they have some differences in methods of transport and how they support certain features they will not be 100% compatible.

It would probable be a lot easier to add support for ATSC to the DVB API than it would be to start a new api. Not to mention keeping dependanciy related issues to a min.
Re: Don't have a cow man
PostPosted: Sun Feb 01, 2004 3:20 pm Reply with quote
Joined: 06 Nov 2003
Posts: 95
Location: Aptos,CA,USA

neotinker wrote:
As for DVB supporting ATSC the short answer is yes but the long answer is no.
ATSC is simply an extention of the mpeg transport stream protocal which is also used by DVB so there should be some overlap but since they have some differences in methods of transport and how they support certain features they will not be 100% compatible.

It would probable be a lot easier to add support for ATSC to the DVB API than it would be to start a new api. Not to mention keeping dependanciy related issues to a min.

Just so I understand it better, I'm going to try to get both the bttv patches and a new DVB driver interface to work, if possible (I may give up as soon as it gets hard), just so I know which one is better once I did both. I may run out of time once I finish hacking on the bttv driver. Thank you for your post. I have to go now, so can't read and respond more.
View user's profile Send private message Send e-mail
Re: Linux 2.6.2 driver available.
PostPosted: Thu Feb 05, 2004 4:30 pm Reply with quote

A. No jitters. Had to increase jiffie waits in getsignalstrength routine. It wasn't getting correct data from the card (they were arriving out of order, out of sync, etc.; perhaps still a bug in I2C interaction? If so, please tell me how to fix.)

Jiffies are not a good way to wait on hardware. They are variable in length, the default value in 2.4 is 10 msec, and the default value in 2.6 is 1 msec. But this is a variable. If you have a fast machine and are doing low-latency stuff like real-time audio or video you can make the jiffies shorter, and if you are running batch jobs you make it larger. They are basically a measure of how long an application can depend on running uninterupted by another application by the pre-emptive kernel. If you want to use jiffies you should query the kernel first about how many of them it is generating per second.

I hope this helps.
Re: Linux 2.6.2 driver available.
PostPosted: Mon Feb 09, 2004 4:12 am Reply with quote
Joined: 06 Nov 2003
Posts: 95
Location: Aptos,CA,USA

Jiffies are not a good way to wait on hardware. They are variable in length, the default value in 2.4 is 10 msec, and the default value in 2.6 is 1 msec.

Thank you: everything you said was very helpful, because it confirmed everything I thought.

Luckily, pcHDTV left notes in bttv-atsc/drv/dvr.c saying how many milliseconds it wants in each case. We should normalize that somehow; someone should make a function that tests the speed of measurement and speeds needed, since some HW will have different tolerances than others, and then make it wait that long. To do that, we'd need some simple things:

* HW requirements, so we know how long to make it wait;
* a function that knows how long and what time measurements to use (e.g., jiffies, but you said they're not the right thing to use).

Anyway, I can't do it now. I suggest people with trouble just hack those values and if resources permit finally make a more portable function set for those at some point. I would definitely do all that if I had more time, but I don't (see edit to my message above, which says I have to stop working on this to find work).
View user's profile Send private message Send e-mail
PostPosted: Mon Feb 09, 2004 11:30 am Reply with quote
Joined: 15 Jan 2004
Posts: 22

FYI: The -3g patch applies cleanly (with a few line offsets) to 2.6.3-rc1. I believe that -rc1 included some video patches, so that's good news. I hope to test it tonight.

Any thoughts on trying to get this driver included in the standard kernel? With the addition of a separate config option, it should be easier now.
View user's profile Send private message
PostPosted: Tue Feb 10, 2004 4:35 pm Reply with quote
Joined: 15 Jan 2004
Posts: 22

No go with the -3g driver and 2.6.3-rc1. With the driver compiled into the kernel, it died during initialization. I didn't copy the entire trace, but here's the top line:
    Call Trace:
    [<c02a7991>] btatsc_setmode+0x191/0x220
View user's profile Send private message
PostPosted: Wed Feb 11, 2004 6:54 am Reply with quote

Has anyone successfully used pcHDTV with linux-2.6.2? The patch applied cleanly and the module inserts ok and detects the hardware. But when I try to record either ATSC on dtv or NTSC on video0 I get:

kernel: bttv0: IRQ lockup, cleared int mask [bits: OFLOW GPINT*]

Over and over in my logs. And no video.

Any ideas what needs to be worked?
PostPosted: Wed Feb 11, 2004 7:56 am Reply with quote
Joined: 15 Jan 2004
Posts: 22

The card doesn't have an MPEG encoder, so NTSC has to be encoded in software. Unless things have changed, you use /dev/video0 for that. ATSC is already in an MPEG transport stream, so it's digital data to begin with--completely unlike NTSC. You use /dev/video32 for ATSC. (PAL is much like NTSC in this regard, but I don't know of anyone who would be receiving ATSC and PAL in the same location.)

So try /dev/video32 and see how that works.
View user's profile Send private message
PostPosted: Wed Feb 11, 2004 2:50 pm Reply with quote

crow wrote:
No go with the -3g driver and 2.6.3-rc1. With the driver compiled into the kernel, it died during initialization. I didn't copy the entire trace, but here's the top line:
    Call Trace:
    [<c02a7991>] btatsc_setmode+0x191/0x220

This looks like the problem I was having with 2.6.2, if you have i2c debugging turned on, then turn it off. The bug appears to still exist in 2.6.3-rc1. Looks like it was fixed in rc2.

PostPosted: Wed Feb 11, 2004 3:46 pm Reply with quote

I guess I should have been more clear on that post.
With the Linux 2.4 series I was capturing transport streams on /dev/dtv (alternate device name for /dev/video32) and also grabbing NTSC with the V4L framegrabber on /dev/video0. Both worked fine.

The question basically was: is the driver for 2.6.2 broken? Cuz it don't work. I'll look into this more on my own, but I was just curious if anyone out there is using 2.6.2 with pcHDTV or if it needs more development first.
Linux 2.6.2 driver available.
  pcHDTV Forum Index -> HD-2000/3000 drivers
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
All times are GMT - 7 Hours  
Page 1 of 4  
Goto page 1, 2, 3, 4  Next
 Post new topic  This topic is locked: you cannot edit posts or make replies.  

Powered by phpBB © 2001-2003 phpBB Group
Theme created by Vjacheslav Trushkin