[12:35] <bigcats_fl> vnc config question?  is there /etc file, or under X11??
[12:36] <superm1> hi bigcats_fl
[12:36] <superm1> which config file do you mean?
[12:36] <superm1> to turn on VNC for the X session?
[12:59] <laga> superm1: no, trunk packages are not fully merged yet. i'm still haing trouble with debconf stuff but i haven't investigated further yet.
[12:59] <laga> gotta go now :)
[12:59] <superm1> laga, alright
[03:03] <foxxbuntu> superm1, hows portland?
[03:31] <foxbuntu> superm1, you there?
[03:47] <foxbuntu> superm1, ...here now?
[03:48] <foxbuntu> hey superm1_
[03:48] <superm1_> hi foxbuntu
[03:48] <foxbuntu> hows the coast?
[03:49] <superm1_> coast?
[03:49] <superm1_> I'm not there yet
[03:49] <foxbuntu> Oh, I thought you were flying out there friday
[03:49] <superm1_> I am
[03:49] <superm1_> its not friday yet
[03:49] <foxbuntu> this friday
[03:49] <foxbuntu> I thought it was last friday
[03:49] <superm1_> Nope
[03:50] <foxbuntu> k
[03:50] <foxbuntu> hey
[03:50] <foxbuntu> does Xgl have its own package or do i have to do some crazy crap to get it to work
[03:51] <superm1_> imo it's not worth the effort to do things with Xgl
[03:51] <superm1_> because too much other stuff breaks
[03:51] <superm1_> when you need to work around things
[03:51] <foxbuntu> hmm
[03:51] <superm1_> i had a howto written many months ago how to get around every issue i ran into
[03:51] <foxbuntu> I have a package i wanted to try out but it depends on Compiz which needs Xgl
[03:52] <superm1_> compiz fusion doesn't need "xgl"
[03:52] <superm1_> it just needs support for texture from pixmap
[03:52] <superm1_> which you can get if you use the open source ati driver
[03:53] <foxbuntu> so what do I have to do other than switch to vesa?
[03:54] <superm1_> switch to the 'ati' driver
[03:54] <superm1_> if its supported by your card
[03:54] <superm1_> rather than fglrx
[03:54] <foxbuntu> oh
[03:54] <superm1_> what card do you have?
[03:54] <foxbuntu> x600
[03:55] <superm1_> oh well you may not be supported on the open source one then.
[03:56] <foxbuntu> hmm
[03:59] <foxbuntu> eh...gonna give it a try
[03:59] <foxbuntu> brb
[04:01] <foxbuntu> superm1, http://paste.ubuntu-nl.org/30176/
[04:01] <foxbuntu> thats the output when I run compiz
[04:02] <foxbuntu> the ATI driver does seem to work however
[04:02] <foxbuntu> superm1_, see above
[04:02] <rogue780> foxbuntu, you won't get compiz or beryl or compiz fusion to work with ATI. it won't happen. let it go.
[04:03] <foxbuntu> NO...
[04:03] <foxbuntu> lol
[04:03] <foxbuntu> :P
[04:03] <rogue780> I tried for months...although it was for my laptop with a ati mobile X1300
[04:03] <foxbuntu> I had beryl working on this machine at one time
[04:04] <foxbuntu> but the was Edgy
[04:04] <superm1_> foxbuntu, really it's not worth the trouble
[04:04] <superm1_> i'm telling you
[04:05] <foxbuntu> your raining on my parade here
[04:05] <foxbuntu> I want to install AWN
[04:06] <rogue780> I want to install Battlefield 2142 and Civilization IV...but hey, linux ain't perfect
[04:06] <rogue780> oh and Supreme commander (I love games....only reason to keep windows around)
[04:07] <rogue780> ;)
[04:12] <superm1_> foxbuntu, i saw awn today too, and yea it looks neat - but still not worth the effort with making Xgl and all the hacks associated with it work
[04:19] <foxbuntu> superm1_, you know me though, I am a gluten for punishment
[04:22] <foxbuntu> anyhow
[04:23] <foxbuntu> did you catch my blueprint on add'l ati and nvidia drivers?
[04:23] <superm1_> no i didn't
[04:23] <superm1_> link?
[04:24] <foxbuntu> https://blueprints.launchpad.net/mythbuntu/+spec/video-card-detection-updates
[04:24] <foxbuntu> its really just a thought atm
[04:24] <superm1_> well that's really not something mythbuntu specific
[04:24] <superm1_> its a ubuntu thing
[04:25] <superm1_> and newer drivers are included in gutsy
[04:25] <foxbuntu> but the driver packages from Nvidia/Ati resolve the issue
[04:25] <superm1_> what are you referring to
[04:27] <foxbuntu> well one user last night has a brand new board with HDMI out and tried mythbuntu but failed becuase he didn't know how to install the driver package from Nvidia on there, which he thought that it would detect it
[04:27] <superm1_> what driver supports hdmi?
[04:27] <superm1_> and what driver is in ubuntu gutsy?
[04:27] <foxbuntu> the new NVIDIA package
[04:27] <superm1_> not just "new"
[04:27] <superm1_> number
[04:28] <superm1_> because there are "new" driver in gutsy, but perhaps you are referring to a beta driver
[04:29] <foxbuntu> well I didnt get a version number but I will go find it
[04:29] <superm1_> the "newest" driver is this: http://www.nvidia.com/object/linux_display_ia32_100.14.11%20.html
[04:29] <superm1_> and it claims nothing about HDMI
[04:29] <superm1_> and i dont see HDMI in release highlights for the previous 4 or so
[04:29] <superm1_> before that
[04:31] <foxbuntu> let me figure out which one
[04:31] <foxbuntu> oh, superm1_ I bought a truck today
[04:33] <foxbuntu> superm1_, the Ati card the guy was refering to is the ATI Xpress 1250
[04:34] <superm1_> the driver 8.37.6 is included in gutsy
[04:34] <foxbuntu> hmm
[04:34] <superm1_> the latest is 8.38.6
[04:34] <superm1_> which does add support for the xpress 1200 series
[04:34] <foxbuntu> maybe he was using the 7.04 ISO
[04:35] <foxbuntu> oh so
[04:35] <foxbuntu> it does need a different package
[04:36] <superm1_> well it's just a matter of when ubuntu upgrades the restricted drivers package
[04:36] <foxbuntu> ok
[04:36] <foxbuntu> was just a thought
[04:36] <superm1_> well i mean the only problem is
[04:37] <foxbuntu> but FYI
[04:37] <foxbuntu>  NVIDIA GeForce 7050 PV and nForce 630a
[04:37] <foxbuntu> Featuring NVIDIA PureVideo technology with HDMI, deliver 20% better HD video quality along with best-in-class 3D performance.
[04:37] <superm1_> that if you step on the feet of ubuntu
[04:37] <superm1_> then you have to recompile drivers after every kernel upgrade
[04:37] <foxbuntu> thats what the new Nvidia driver adds support for
[04:37] <superm1_> well purevideo isn't support in linux
[04:37] <superm1_> so i'm not sure where you're reading that
[04:38] <foxbuntu> strange though, he claimed to have it working with the package from NVidia
[04:38] <superm1_> hdmi probably
[04:38] <superm1_> but not purevideo
[04:38] <foxbuntu> well HDMI yes
[04:38] <superm1_> hdmi is indeed just dvi with audio on the cable
[04:38] <foxbuntu> right
[04:39] <foxbuntu> but that GPU and chipset are the added features of the new NVidia driver
[04:40] <superm1_> again, the mythbuntu blueprints aren't the place for that though.  Ubuntu kernel team will update them
[04:41] <foxbuntu> ok
[04:41] <foxbuntu> wasn't sure where to drop it so I just dropped it there for now
[04:42] <foxbuntu> and you can nuke it since its improper
[04:42] <foxbuntu> rb
[04:42] <foxbuntu> brb
[04:47] <superm1_> back in a bit
[05:59] <foxbuntu> GAA
[05:59] <foxbuntu> parsing is driving me nutz
[06:00] <foxbuntu> anyone here good with pyparsing?
[03:22] <rogue780> #photography
[04:56] <superm1_> keescook, you here?
[05:01] <keescook> superm1_: yup, but in a meeting.  what's up?
[05:02] <superm1_> keescook, i was just looking to see if you could look over a debdiff of something in main
[05:02] <superm1_> no rush though.
[05:02] <superm1_> later on you can take a look, bug #126565
[05:02] <ubotu> Launchpad bug 126565 in base-files "LGPL v3 is not included" [Undecided,Confirmed]  https://launchpad.net/bugs/126565
[05:12] <keescook> superm1_: cool, looks good.  I'll upload it shortly...
[05:49] <Kenzu> hey...
[05:49] <superm1> Hey Kenzu
[05:49] <Kenzu> Anyone with an imon remote?
[05:49] <Kenzu> imon pad
[05:51] <Kenzu> The usbstick install and my epia m1000 is not happy.... It's slow and chuppy i picture when caching or loading on usb
[05:52] <superm1> thats a shame :(
[05:52] <superm1> Kenzu, you were the one with the bug regarding the name of the usbstick right?
[05:52] <Kenzu> So I think maybe a dedicated usb install/ setup would be better...
[05:53] <Kenzu> for now Ill go back to archlinux/larch for my epia and usb stick
[05:53] <Kenzu> Yes that was me
[05:53] <superm1> Well that bug has been resolved - such things shouldn't happen anymore
[05:54] <superm1> as for the slow speed - can you run hdparm on a usbstick possibly?
[05:54] <Kenzu> superm1: yeah I could se that in my mailboks
[05:56] <Kenzu> superm1: booting it up now...
[05:58] <Kenzu> superm1: still booting
[05:59] <superm1> haha
[05:59] <superm1> i see it's quite slow then :)
[06:00] <Kenzu> superm1: now mythfrontend is starting
[06:01] <Kenzu> but I think the choppy video is because of missing dri
[06:01] <Kenzu> and xvmc
[06:02] <Kenzu> superm1: hdparm options?
[06:03] <Kenzu>  Timing buffered disk reads:   46 MB in  3.06 seconds =  15.03 MB/sec
[06:03] <superm1> use hdparm to query the info about the drive
[06:03] <Kenzu> setup@epia-frontend:~$ hdparm /dev/sda1
[06:03] <Kenzu> /dev/sda1:
[06:03] <Kenzu>  readonly      =  0 (off)
[06:03] <Kenzu>  readahead     = 256 (on)
[06:03] <Kenzu>  geometry      = 246/255/63, sectors = 192717, start = 63
[06:04] <superm1> do it on /dev/sda
[06:04] <superm1> not just sda1
[06:05] <Kenzu> /dev/sda:
[06:05] <Kenzu>  readonly      =  0 (off)
[06:05] <Kenzu>  readahead     = 256 (on)
[06:05] <Kenzu>  geometry      = 246/255/63, sectors = 3963904, start = 0
[06:06] <superm1> oh still didn't say what i was hoping - okay then there isn't much to tweak with hdparm on a usbstick
[06:07] <superm1> if you'd like to check the info about dri
[06:07] <superm1> glxinfo | grep direct
[06:07] <Kenzu> on larch it a readonly filesystem and it's compressed = much better speed
[06:08] <superm1> well again, my autostart stuff that will allow you to boot from cd and keep a configuration file on the usbstick may be a modest improvement then, but i'm still working on it
[06:08] <Kenzu> I think we have to think about the usbstick as a livecd
[06:09] <Kenzu> so if we put the livecd iso on the stick and make 3 partitions, one for boot, one for the iso and one for session saving
[06:09] <superm1> why would that be faster though?
[06:10] <Kenzu> because of the readonly compressed filesystem on the livecd
[06:10] <superm1> i would think decompressing squashfs on the fly to be much slower
[06:10] <superm1> my example at hand
[06:10] <Kenzu> and it will save your usbstick for a lot of write time
[06:10] <superm1> in a virtual machine
[06:11] <superm1> if i have an iso image mounted
[06:11] <superm1> and i have a virtual hard drive mounted
[06:11] <superm1> the boot time to the virtual hard drive is much much faster after a fresh mythbuntu install versus a live iso boot
[06:11] <superm1> same content on both of them
[06:11] <superm1>  but the live iso has to decompress a large read only file system
[06:12] <Kenzu> I se your point... but againg larch is much faster than mythbuntu install on usbstick
[06:13] <Kenzu> and the usbstick mythbuntu is on has better readspeed than the 512 larch is on
[06:13] <Kenzu> so I don't now how they do it in larch
[06:13] <superm1> well perhaps you can do an experiment then -
[06:14] <superm1> with the iso sitting on the stick
[06:14] <superm1> and enabling a partition for writing with casperfs
[06:14] <superm1> I'm not sure of the technical requirements for it - but it would be a worthwhile experiment if you could sort it out
[06:15] <superm1> and would provide a sure answer as to the improvement seen
[06:15] <Kenzu> but the iso is not going to be like an iso file on the stick? but unpacked
[06:15] <superm1> well you can unpack it, and allow it to be readonly and such
[06:16] <superm1> i'm still not sure the proper way to compress it
[06:16] <superm1> and allow it to be bootable
[06:16] <tgm4883> jumping in on this, are we just trying to stick the live disk on a bootable usb key?
[06:17] <Kenzu> https://help.ubuntu.com/community/Installation/FromUSBStick?highlight=%28usbstick%29
[06:18] <Kenzu> thats the way to go I think
[06:18] <Kenzu> http://www.pendrivelinux.com/2007/01/25/usb-x-ubuntu-610 or this
[06:19] <tgm4883> i dont think that will make it writable though, if thats what your after
[06:19] <Kenzu> no... but it will save your settings on the casper partition?
[06:20] <Kenzu> but please take a look at this http://four.fsphost.com/gradgrind/dev3A/index.html because that has proven to be fast on my epia
[06:22] <superm1> Well if you expand upon that you can make another partition
[06:22] <superm1> with a casperfs
[06:22] <superm1> and allow it to be appendable
[06:22] <superm1> there is a boot parameter to pass to the kernel
[06:22] <superm1> that does this
[06:24] <tgm4883> https://wiki.ubuntu.com/LiveUsbPendrivePersistent
[06:25] <tgm4883> i haven't done it since edgy though, and even that was a usb hard drive
[06:26] <tgm4883_laptop> are we looking for speed or noise reduction?
[06:27] <superm1> tgm4883_laptop, it's for a mythbuntu install on a usb drive
[06:27] <superm1> rather than hard drive
[06:27] <superm1> its slow for him
[06:27] <Kenzu> power saving and noise.... the frontend is pasive cooled and is going to be always on in my bedroom
[06:27] <tgm4883_laptop> right, and for writing purposes, the install on the usb drive has to be in persistant mode
[06:27] <superm1> he managed to achieve an install to the pen drive
[06:27] <superm1> from ubiquity
[06:27] <Kenzu> just to save my usbsticks live
[06:28] <Kenzu> life
[06:29] <tgm4883_laptop> so the question is, is it better to install the system to the usb drive or have a live cd on a usb drive?
[06:30] <tgm4883_laptop> or are we just working on bugs
[06:30] <superm1> well we're trying to brainstorm the best install method
[06:30] <superm1> when using a usbstick
[06:30] <superm1> my current mythbuntu work is on something that will provide one solution to this problem via storing a configuration file on a usbstick
[06:30] <superm1> but doing an entire boot from cd
[06:31] <tgm4883_laptop> well the easiest (assuming it works) would be to install to the usb stick as sticking a live cd on a usb disk is more work
[06:31] <tgm4883_laptop> how big is the live cd frontend market?
[06:31] <superm1> well currently i'd say very small - but if its more feasible to do so via the method i'm writing
[06:31] <superm1> it might grow
[06:32] <superm1> then you can bring a live cd and usbstick around with you and boot a frontend on the fly
[06:32] <superm1> say a windows only box that you wanted to run myth on for a bit
[06:32] <superm1> Kenzu is proposing an alternate partitioning scheme instead
[06:33] <superm1> where the contents of the filesystem are stored on a read only partition
[06:33] <superm1> and then you have a casperfs partition that changes are written to
[06:33] <Kenzu> if it could be possible to make it fit on a 512mb stick it would be god... because 512mb has better bios support
[06:33] <tgm4883_laptop> i always thought of it more as a testing market, as with a live cd frontend, cd drives tend to be loud when running at full speed, slower.  If you want to watch a dvd you need two drives, etc
[06:33] <superm1> unfortunately, there will be no way to really gauge how much it's used
[06:34] <superm1> but i see your point there
[06:34] <tgm4883_laptop> that shouldn't be a problem, should it?  The live cd is < 400MB
[06:34] <superm1> well currently its at 406
[06:34] <superm1> because of some added support i put in
[06:34] <superm1> but once you extract it, it can grow up to 1.5 GB
[06:35] <tgm4883_laptop> I agree that a usb key would be easier carry around, quieter, etc
[06:35] <tgm4883_laptop> it can be compressed though
[06:35] <superm1> do you know how to do so?
[06:35] <tgm4883_laptop> and should be faster
[06:35] <tgm4883_laptop> sec
[06:36] <superm1> because if its a standard ext2/3 filesystem on the key, i don't see how thats possible
[06:36] <tgm4883_laptop> your talking about installing to the usb key?
[06:37] <tgm4883_laptop> im talking about sticking the live cd on a usb key
[06:37] <superm1> well that shouldn't be much of any trouble
[06:37] <tgm4883_laptop> so as long as the live cd fits in 800MB, then all we need is roughly a 1 gb stick
[06:38] <Kenzu> tgm4883_laptop: 1GB stick is hard to boot... not all bioses like it...
[06:38] <tgm4883_laptop> the question though, is do we really need write support
[06:38] <tgm4883_laptop> Kenzu, right, but thats the max we would need.  It all depends on the size of the live cd
[06:38] <superm1> well No
[06:38] <superm1> if its two partitions
[06:38] <superm1> and one just stores the configuration file as i described
[06:39] <tgm4883_laptop> im wondering if we need write support at all
[06:39] <superm1> then the entire system can be achieved read only
[06:39] <superm1> it will be a little slow upon boot to generate thumbnails
[06:39] <superm1> and cache artwork
[06:39] <superm1> but should be fine after a little bit
[06:39] <tgm4883_laptop> anything on a usb stick should be quicker than a live cd no?
[06:39] <superm1> depends if usb2 is active upon boot
[06:40] <tgm4883_laptop> true
[06:40] <superm1> which can possibly be where the problem here was even coming from
[06:40] <Kenzu> maybe we could make a script that makes 3 partitions. installs grub, kernel on the first, unpack the iso on the secound, and makes a casperfs on the last
[06:41] <superm1> last doesn't even need to be casperfs if its just the conf file.  it can be ext2/3
[06:41] <superm1> or even fat
[06:42] <Kenzu> but if it could save the theme caching in and overlay file on the casperfs
[06:42] <Kenzu> then boot will be faster
[06:42] <superm1> oh that's a good point
[06:43] <superm1> well i think ~/.mythtv can be redirectd
[06:43] <superm1> if you just adjust $HOME
[06:43] <superm1> before launching it
[06:43] <tgm4883_laptop> wait question, if your carrying around this usb key to show other people, you stick it in their computer and boot it up, voila, what do you show them?
[06:43] <superm1> so it wouldnt even need to be casperfs
[06:43] <superm1> well eventually - i'd like to see a live backend / frontend working
[06:43] <Kenzu> you put in another usbstick or a cd or dvb-t stick
[06:44] <superm1> but that depends on a few other specs to be worked out
[06:44] <superm1> hey Chadarius
[06:45] <tgm4883> home doesn't have to be /home
[06:46] <superm1> so in the autostart, if i query if the directory that the configuration file is writable - maybe just redirect home to be there
[06:46] <superm1> when launching
[06:49] <superm1> i'm purposely trying to avoid having to make that partition casperfs
[06:49] <superm1> because i dont think its right that someone would have to wipe their usb stick just for this
[06:49] <superm1> they should be able to use an existing one with some freespace
[06:50] <tgm4883> casper was a friendly ghost, but I don't think he's a good candidate
[06:50] <Kenzu> come on they are so cheep
[06:50] <tgm4883> is the bios support for 512MB usb drives due to them being 512MB or partition size?
[06:51] <Kenzu> partition size... something about 1023 cylinders
[06:51] <tgm4883> so if you had a 4 gb stick with 8 512 partitions you would be fine?
[06:57] <Kenzu> no only the first partition (boot) has to be in the first 1023 cylinders or 512mb
[06:57] <Kenzu> setup@epia-frontend:~$ fdisk -l
[06:57] <Kenzu> Disk /dev/sda: 2029 MB, 2029518848 bytes
[06:57] <Kenzu> 255 heads, 63 sectors/track, 246 cylinders
[06:57] <Kenzu> Units = cylinders of 16065 * 512 = 8225280 bytes
[06:57] <Kenzu>    Device Boot      Start         End      Blocks   Id  System
[06:57] <Kenzu> /dev/sda1               1          12       96358+  83  Linux
[06:57] <Kenzu> /dev/sda2              13         246     1879605   83  Linux
[06:57] <tgm4883> so why are we even worrying about the size of the usb key then?
[06:57] <Kenzu> that's my 2GB stick with mythbuntu
[06:57] <Kenzu> not the size of the usb but the size of the iso
[06:57] <Kenzu> it has to fit in the first 512mb
[06:57] <Kenzu> or you will have to make a boot partition
[06:57] <tgm4883> right, and the down side of a boot partition?
[06:59] <Kenzu> it's harder for a newbee
[06:59] <Kenzu> ok now my video i running fine... it was a dri problem
[07:00] <tgm4883> i though we were trying to get around that, ie having an install to usb option
[07:01] <Kenzu> that could be good
[07:01] <superm1> so this install to usb option, it would be a bit complicated to do right
[07:02] <superm1> because building that compressed squashfs filesystem means that you have to extract somewhere first
[07:03] <Kenzu> hmm... now it crash when exiting the guide
[07:05] <Kenzu> somethins about drm and agp ringbuffer
[07:17] <superm1> Daviey, you here?
[11:26] <superm1> keescook, that plan that you had had with udev, i was talking to the mkrufky today about it.
[11:26] <superm1> we might have brainstormed a better idea
[11:27] <keescook> oh! excellent.  I'm all ears.  the v4l people weren't very receptive, and to do it "right" requires a lot of kernel work in v4l
[11:27] <superm1> all pvr-xxx devices getting /dev/pvrX rather than /dev/videoX.  all other non dvb devices getting /dev/videoX
[11:27] <keescook> how about just symlinks?
[11:27] <superm1> well symlinks wouldn't do it, because they would still be assigned
[11:28] <superm1> for videoX on pvr devices
[11:28] <keescook> meaning mythtv would try to add them both?
[11:28] <superm1> right
[11:28] <keescook> yeah, hurm
[11:28] <superm1> well actually
[11:28] <superm1> if upstream doesn't take kindly to this
[11:28] <keescook> I worry about breaking things that aren't mythtv
[11:28] <superm1> symlinks and a mythtv patch
[11:29] <superm1> could do it
[11:29] <keescook> that might work.
[11:29] <superm1> i dont know how much other stuff would really be broken though
[11:29] <superm1> because what other apps are able to capture from pvr videoX devices?
[11:29] <superm1> most don't know what to do with the mpeg2 data
[11:30] <keescook> right, but is there a way to tell an mpeg2 device from a "regular" video-cap device?
[11:30] <superm1> well pvr cards are the only ones that do the mpeg2 thing though aren't they?
[11:31] <keescook> well, there are others that come from a different brand.
[11:31] <keescook> I suppose there must be some common driver for only mpeg2 cards
[11:31] <superm1> i wasn't aware anything other than the ivtv driver did such things
[11:31] <keescook> yeah, I don't think there is.  so if a device is from the ivtv, we can make a symlink.
[11:32] <keescook> then only the ivtv init order matters, and I think that's the same as long as you leave your cards in the same slots.  ;)
[11:32] <superm1> well i dont know that it is always the same for that even
[11:32] <keescook> so, adding a udev hook in mythtv-backend is probably the best way to go
[11:32] <superm1> because of race conditions in upstart
[11:33] <keescook> I'm pretty sure per-driver init order is static.
[11:33] <superm1> oh really.
[11:33] <keescook> I'm not 100% sure, but I don't have multiple ivtv devices to test with
[11:33] <superm1> then there is the solution then (provided of course upstream's opinion on the matter is negative)
[11:33] <superm1> mkrufky, meet keescook keescook meet mkrufky
[11:34] <mkrufky> hi
[11:34] <keescook> hiya mkrufky
[11:34] <mkrufky> i think we may have spoken before
[11:34] <mkrufky> either that, of i stalked some other chat room while you were speaking ;-)
[11:34] <superm1> keescook and i were discussing matters of switching to pvrX for ivtv cards
[11:34] <mkrufky> s/of/or
[11:34] <superm1> and keescook brought up the question, do any other cards spit out mpeg2 via /dev/videoX other than ivtv?
[11:35] <mkrufky> yes
[11:35] <mkrufky> cx88-blackbird and pvrusb2
[11:35] <mkrufky> also. .. saa7134-empress
[11:35] <mkrufky> and that plextor device
[11:35] <mkrufky> i forget it's actual name
[11:35] <keescook> is there any common element we can use to distinguish them from non-mpeg2 devices?
[11:35] <superm1> so then even if ivtv upstream was to be convinced to use pvrX instead, there are still a few cards to break the naming convention
[11:35] <mkrufky> ....and some new devices whose drivers have yet to be released
[11:35] <mkrufky> well
[11:36] <mkrufky> it's not really up to ivtv to decide
[11:36] <keescook> I with the v4l drivers had more details in their sysfs tree
[11:36] <mkrufky> it would be a v4l2 decision
[11:36] <keescook> I wanted to build device symlinks in udev with:
[11:36] <keescook> KERNEL=="video[0-9] *", ATTR{name}!="", SYMLINK+="video-$attr{name}"
[11:36] <mkrufky> brb
[11:36] <keescook> or something similar
[11:37] <keescook> if there are serial numbers or something available for a given board, we could save their locations as is done for drives and net devices.
[11:37] <superm1> via uuid's?
[11:37] <keescook> at the very least, we should be able to build udev rules for the "by-path" via the PCI id.
[11:37] <mkrufky> im sorry... this is the busiest time of my day
[11:37] <mkrufky> leaving the office any minute, brb
[11:39] <mkrufky> yeah, i see nothing wrong with that
[11:39] <superm1> i think that udev rule shouldn't just be mythtv-backend specific either
[11:39] <superm1> because i'm sure users of tvtime and the kde tv application have the same issue
[11:40] <superm1> its just not as publicized as it is with mythtv
[11:40] <keescook> superm1: agreed, it would probably live with udev
[11:40] <mkrufky> yes
[11:40] <superm1> but after the rule is in place, a patch to mythtv (at least for ubuntu) to parse the /dev/by-path instead of /dev/v4l should be in place i'd think
[11:40] <mkrufky> v4l is certainly in need of a better sysfs tree.
[11:40] <keescook> here's where I started some discussion: http://marc.info/?l=linux-video&m=118064286307150&w=2
[11:42] <superm1> Mauro brings up a good point that there are other devices created too
[11:43] <superm1> mkrufky, is there a spec for making a better sysfs tree in process right now?
[11:43] <mkrufky> vbi, radio
[11:43] <mkrufky> not that i know of, no
[11:43] <mkrufky> im more into the dvb stuff, TBH
[11:44] <superm1> ah okay.
[11:44] <mkrufky> the dvb cards all have MAC addresses, and there was talk of using that, wrto dvb
[11:44] <superm1> that would make a lot of sense
[11:45] <mkrufky> there are ways to relate the dvb devices back to the video devices ....  but bttv doesnt do it correctly yet ... only cx88 and saa713x
[11:45] <keescook> well perhaps rules to handle the missing info gracefully?
[11:46] <mkrufky> if you guys will be around tomorrow, im sure i could be much more productive
[11:46] <superm1> sure
[11:46] <keescook> cool
[11:46] <mkrufky> this is just bad timing right now
[11:46] <mkrufky> im sorry
[11:46] <superm1> no biggie
[11:46] <superm1> well i do think a rule that at least links the pci id for now should be put into place, i think its a very good start
[11:46] <superm1> because mythtv already queries the device
[11:46] <superm1> and tells you what it is
[11:46] <mkrufky> you cant rely on that
[11:47] <mkrufky> oh, pci id ... that you can probably rely on
[11:47] <mkrufky> i was thinking, subsystem id
[11:47] <mkrufky> some cards lack an eeprom and thus, lack subsystem id ....  but that irrelevant -- sorry :-)
[11:47] <superm1> so if mythtv parses from /dev/by-uuid or something to that effect, and sees all these videoXXXXXXXXX devices, it won't matter which is which, since it will tell you what it finds out about the card
[11:48] <mkrufky> yeah
[11:48] <superm1> the same thing can probably be done with the dvb devices too?
[11:49] <mkrufky> i see no reason why not
[11:49] <mkrufky> this is _much_ better than your /dev/video11 idea, superm1
[11:49] <superm1> hehe
[11:50] <mkrufky> anyhow, i have to go now
[11:50] <mkrufky> i'll come back here tomorrow
[11:50] <superm1> okay thanks mkrufky ! have a good one
[11:50] <mkrufky> you too
[11:50] <mkrufky> nice to meet you keescook, too
[11:50] <keescook> same to you!
[11:50] <mkrufky> ok, have a good one
[11:50] <superm1> keescook, i'll investigate the complexities of a mythtv patch later this evening
[11:50] <keescook> okay, cool
[11:50] <superm1> where will it need to query from?
[11:52] <superm1> /dev/v4l/by-id?
[12:08] <superm1> keescook, ?
[12:08] <keescook> superm1: probably, yeah