List: linux-video Subject: [video4linux] new API From: Bill Dirks <dirks () rendition ! com> Date: 1998-08-20 2:57:02 Alan, What are the plans regarding my spec proposals? Is that planned on being incorporated or not? I haven't really gotten any feedback from you on it. If it's going in, do you need some help with it? I'm not doing much with my driver right now pending the new specs. I'm quite willing to help out any way I can. I also want to write a CODEC spec to go with the capture spec. The CODEC spec can use many data structures and ioctls from the capture spec. But it's clearly pointless to do that unless I know the capture specs will be adopted. There are things I eventually want to add the my driver, for example streaming capture and compressed capture, that are waiting for new APIs. I got a lot of positive feedback on the proposals, and I think it extends v4l in important ways beyond its bttv roots and opens doors for integrating future capabilities. Not to mention I've had a lot of fun working with v4l and writing my driver, and I'd hate to see it peter out. :) Regards, Bill. ------------ To unsubscribe from this list send mail to majordomo@phunk.org with the line "unsubscribe video4linux" without the quotes in the body of the message.
List: linux-video Subject: Re: [video4linux] new API From: Alan Cox < alan () cymru ! net> Date: 1998-08-20 12:35:29 > What are the plans regarding my spec proposals? Is that planned on being > incorporated or not? I haven't really gotten any feedback from you on > it. Sorry, I've been very busy > If it's going in, do you need some help with it? I'm not doing much with > my driver right now pending the new specs. I'm quite willing to help out > any way I can. For 2.1.116 I've simply fixed the obvious screwups. Since we are in a code freeze I cant do much more for that > I also want to write a CODEC spec to go with the capture spec. The CODEC > spec can use many data structures and ioctls from the capture spec. But > it's clearly pointless to do that unless I know the capture specs will > be adopted. I need to go and re-read it. I like the idea of things working more akin to plumbing. > There are things I eventually want to add the my driver, for example > streaming capture and compressed capture, that are waiting for new APIs. You've written more video api stuff than I ever have, you've written more video driver code than I probably ever have, why not just go ahead and do it Certainly for the comression/codec stuff I have no useful input other than physical practicalities of implementation ------------ To unsubscribe from this list send mail to majordomo@phunk.org with the line "unsubscribe video4linux" without the quotes in the body of the message.
List: linux-video Subject: Re: [video4linux] new API From: A James Lewis <james () vrtx ! net> Date: 1998-08-20 12:47:51 I know we're in a code freeze, I think it's about time... however where does that leave the API organization for 2.2??? Are we going to be compiling separate modules till 2.4? On Thu, 20 Aug 1998, Alan Cox wrote: > > What are the plans regarding my spec proposals? Is that planned on being > > incorporated or not? I haven't really gotten any feedback from you on > > it. > > Sorry, I've been very busy > > > If it's going in, do you need some help with it? I'm not doing much with > > my driver right now pending the new specs. I'm quite willing to help out > > any way I can. > > For 2.1.116 I've simply fixed the obvious screwups. Since we are in a code > freeze I cant do much more for that > > > I also want to write a CODEC spec to go with the capture spec. The CODEC > > spec can use many data structures and ioctls from the capture spec. But > > it's clearly pointless to do that unless I know the capture specs will > > be adopted. > > I need to go and re-read it. I like the idea of things working more > akin to plumbing. > > > There are things I eventually want to add the my driver, for example > > streaming capture and compressed capture, that are waiting for new APIs. > > You've written more video api stuff than I ever have, you've written more > video driver code than I probably ever have, why not just go ahead and do it > > Certainly for the comression/codec stuff I have no useful input other than > physical practicalities of implementation > ------------ > To unsubscribe from this list send mail to majordomo@phunk.org with the > line "unsubscribe video4linux" without the quotes in the body of the > message. > James (james@linuxrocks.co.uk) Vortex Internet Linux : because everyone's work is mission critical. ------------ To unsubscribe from this list send mail to majordomo@phunk.org with the line "unsubscribe video4linux" without the quotes in the body of the message.
List: linux-video Subject: Re: [video4linux] new API From: Alan Cox <alan () cymru ! net> Date: 1998-08-20 12:59:32 > does that leave the API organization for 2.2??? Are we going to be > compiling separate modules till 2.4? 2.1.116/7 have the minimal changes made so that there is a norm value in the channel, you can specify subareas if the card supports it and you can poll and done in such a way as existing code is source compatible but not binary. The rest is 2.3.x stuff ------------ To unsubscribe from this list send mail to majordomo@phunk.org with the line "unsubscribe video4linux" without the quotes in the body of the message.
List: linux-video Subject: Re: [video4linux] new API From: Gerd Knorr <kraxel () goldbach ! isdn ! cs ! tu-berlin ! de> Date: 1998-08-20 19:34:24 Alan Cox <alan@cymru.net> writes: >> does that leave the API organization for 2.2??? Are we going to be >> compiling separate modules till 2.4? >2.1.116/7 have the minimal changes made so that there is a norm value in >the channel, Which is quite useless in the current form becauce you can't set the norm with VIDIOCSCHAN. I've posted a patch a while ago which changes VIDIOSCHAN to make this work. >poll and done in such a way as existing code is source compatible but >not binary. The 2.1.116 patch breaks both source and binary compatibility for bttv grabbing. >The rest is 2.3.x stuff What about the changes in Ralph's bttv-current? IMHO they are a must-have for 2.2. What about the new i2c layer? For 2.3 ? Gerd -- powered by vim | Gerd Knorr <kraxel@cs.tu-berlin.de> ------------ To unsubscribe from this list send mail to majordomo@phunk.org with the line "unsubscribe video4linux" without the quotes in the body of the message.
List: linux-video Subject: Re: [video4linux] new API From: Alan Cox <alan () cymru ! net> Date: 1998-08-20 20:21:25 > Which is quite useless in the current form becauce you can't set the norm > with VIDIOCSCHAN. I've posted a patch a while ago which changes VIDIOSCHAN > to make this work. Argggggggggggggggggggggggggggghhhhhhhhhhhhhhhhhhh [Stands in the corner with D hat on] Yes I meant to have merged that. Fixed in my tree now. [Sound of headbutting wall] > >poll and done in such a way as existing code is source compatible but > >not binary. > > The 2.1.116 patch breaks both source and binary compatibility for bttv > grabbing. What did I do wrong there. > What about the changes in Ralph's bttv-current? IMHO they are a must-have > for 2.2. Thats in the "bug fix" category so it'll go past Linus fine. Ditto your msp3400 updates > What about the new i2c layer? For 2.3 ? Unfortunately. ------------ To unsubscribe from this list send mail to majordomo@phunk.org with the line "unsubscribe video4linux" without the quotes in the body of the message.
List: linux-video Subject: Re: [video4linux] new API From: Bill Dirks <dirks () rendition ! com> Date: 1998-08-21 0:01:51 Alan Cox wrote: > For 2.1.116 I've simply fixed the obvious screwups. Since we are in > a code freeze I cant do much more for that > [...] > You've written more video api stuff than I ever have, you've written > more video driver code than I probably ever have, why not just go > ahead and do it > > Certainly for the comression/codec stuff I have no useful input other > than physical practicalities of implementation OK, then I hope you don't mind a couple practicality of implementation questions. :) So how does a new version of Linux get born? 2.1.118 or whatever is top-of-stack becomes 2.2.0 (with the original API)? Then there will be a 2.3.0 at the same time, same as 2.2.0? And then the new API goes in 2.3.x, eventually becoming canon in 2.4.0? How do you think I proceed? Tear down and rebuild videodev.[ch], or make a new module with a new name? I favor the latter to make the transition easier. Bill. ------------ To unsubscribe from this list send mail to majordomo@phunk.org with the line "unsubscribe video4linux" without the quotes in the body of the message.
List: linux-video Subject: Re: [video4linux] new API From: Alan Cox < alan () cymru ! net> Date: 1998-08-20 23:12:22 > So how does a new version of Linux get born? 2.1.118 or whatever is > top-of-stack becomes 2.2.0 (with the original API)? Then there will be a > 2.3.0 at the same time, same as 2.2.0? Normally shortly after because initially everyone is busy fixing all the thing sthat always show up after not before release (ie 2.2.1,2.2.2..._) > And then the new API goes in 2.3.x, eventually becoming canon in 2.4.0? Yes, but 2.4 needs to support what 2.2 did > How do you think I proceed? Tear down and rebuild videodev.[ch], or make > a new module with a new name? I favor the latter to make the transition > easier. It actually makes no odds. You can call your module the same thing and export similar facilities and peopel can load either or I doubt videodev.c needs touching much simply because its basically little more than code to track a list of devices and switch calls to them. Alan ------------ To unsubscribe from this list send mail to majordomo@phunk.org with the line "unsubscribe video4linux" without the quotes in the body of the message.
List: linux-video Subject: Re: [video4linux] new API From: Bill Dirks <dirks () rendition ! com> Date: 1998-08-21 0:46:06 Alan Cox wrote: > > And then the new API goes in 2.3.x, eventually becoming canon in 2.4.0? > > Yes, but 2.4 needs to support what 2.2 did So the current videodev.h has to be preserved, or maintained in a 100% backward compatible way? > > How do you think I proceed? Tear down and rebuild videodev.[ch], or make > > a new module with a new name? I favor the latter to make the transition > > easier. > > It actually makes no odds. You can call your module the same thing and > export similar facilities and peopel can load either or How will people be able to load either? Ok, both APIs can't exist at the same time (unless they use different major numbers). But how does the user mechanically choose? Only one version of videodev.h can be in include/linux. > I doubt videodev.c needs touching much simply because its basically little > more than code to track a list of devices and switch calls to them. Probably not, I haven't looked at it. I guess just recognizing CODEC devices, and the select method if it's not there already. Bill. ------------ To unsubscribe from this list send mail to majordomo@phunk.org with the line "unsubscribe video4linux" without the quotes in the body of the message.
List: linux-video Subject: Re: [video4linux] new API From: Alan Cox <alan () cymru ! net> Date: 1998-08-21 1:26:40 > > Yes, but 2.4 needs to support what 2.2 did > > So the current videodev.h has to be preserved, or maintained in a 100% > backward compatible way?# For a few years yes > How will people be able to load either? Ok, both APIs can't exist at the > same time (unless they use different major numbers). But how does the > user mechanically choose? Only one version of videodev.h can be in > include/linux. Your development one doesnt have to be anything to do with the main Linux tree. Ralph distributes his 2.0 video4linux code seperately > Probably not, I haven't looked at it. I guess just recognizing CODEC > devices, and the select method if it's not there already. Alan ------------ To unsubscribe from this list send mail to majordomo@phunk.org with the line "unsubscribe video4linux" without the quotes in the body of the message.