hello, I would like to know if the HP (rebranded Hauppauge) WinTV-HVR-1260 is supported by the linux kernel. I see a page for the Hauppauge WinTV-HVR-1250 here, stating support for linux: http://linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-1250 , but I'm not sure if this includes (WinTV-HVR-1260) or whether these 2 cards are even related. any info on this would be appreciated.
good morning
Hello
Could you tell me whether there is some official way of reporting issues with tvtime and/or cx88 module?
Do I need to subscribe to the mailing list for this purpose?
Tomek_: post to the linux-media mailinglist. No need to subscribe.
Tomek_: make sure you report the kernel version you are using and if you built the driver using the media_build system or not (if you don't know what I'm talking about, then you didn't use it :-) )
thanks, I will
Maybe a dumb question, how to post to this mailing list? Just send email to linux-media@vger....?
yes
OK, thanks a lot!
mchehab: can you confirm that we'll have a media workshop during the kernel summit and on which days that will be? Also anything separate we might want to do with Samsung if that's on a different day.
This so I can book in time (especially the hotel since it seems to be non-refundable!).
hverkuil: I'm planning to
I need to confirm with KS organizers to be 100ure
I'll either ping on IRC or send an email to teh ML after having this confirmed
I understand. I was about to book the hotel, but then I noticed it was non-refundable.
I would like to know if the HP (rebranded Hauppauge) WinTV-HVR-1260 is supported by the linux kernel. I see a page for the Hauppauge WinTV-HVR-1250 here, stating support for linux: http://linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-1250 , but I'm not sure if this includes (WinTV-HVR-1260) or whether these 2 cards are even related. any info on this would be appreciated.
mchehab: I'm also interested in that information for the same reason
although I'll probably spend the week in Korea anyway
qwebirc68344: ask this on the linux-media mailinglist. Steve Toth should know (or should be able to get this info), but he's not often on irc.
pinchartl: I'll let you know as soon as I have confirmation
(likely latter today)
mchehab: s/latter/later/ :-)
:)
it is automatic
I'll do my best to retrain your brain!
there's no duplicate consonants on portuguese, except for one ("ss")
in Spanish, not even that ;)
s/duplicates/duplicate/
lot's of them in dutch...
I thought Spanish had that funny "ll" thing which is actually considered a separate letter but only sorta sometimes..
ah, true
mchehab: finished the review (phew!)
in Portuguese, we use "lh" for the same sound
hverkuil: yeah... we should get rid of those patches and move on...
or at least some of them
every time a rebase is done, I need to respin everything
or a patch reorder
well, nothing can be merged anyway until 4.3-rc1 is released, so there is time.
hverkuil: I'm not worried about merging at this stage...
But I think a lot can be merged at that time, as long as it doesn't touch the public API. At least, that's my opinion.
just worried about not make linux-media users angry by sending huge series of patches
hverkuil: well, we can merge those patches at the media-controller topic branch
the topic branch will be merged back only after we fix the MC problems...
so, it won't affect 4.3-*
although I guess the best is to merge it somewhere after 4.3-rc1, as the media_tree is more tested than the topic branches or developers experimental trees
I don't mind these large patch series: it helps me see how things are building on top of one another.
hverkuil: yes, but I guess other users won't like
(the ones not working directly with MC)
as this makes harder for them to follow other discussions there
this is not something that happens every week. I don't think you should be worried about this.
hverkuil: well, I waited 1 week this time to respin the series, because of its size
it's more important that we get this right.
we should do this right, but long series tend to not attract people to review
as it is easy to lose the focus for the things that are really important
s/as/also/
FYI: from September 23rd to October 10th I'll be traveling (vacation/conferences) and basically be unavailable to do reviews.
good to know
btw, we need to discuss the namespace thing for entitites
pinchartl said he would have some time early this week
I'm gone tomorrow, but I'm available the rest of the week.
pinchartl: when do you have time?
what's the namespace thing?
see hverkuil's comments for patch 31:
https://www.mail-archive.com/linux-media@vger.kernel.org/msg91864.html
and my replies to it
and to a few other patches related to it
basically, it was agreed that we would be removing media types/subtypes from the entity numberspace
so RTTI
mchehab: tomorrow is a mail backlog day that includes your MC patches
what about Wed?
larsc: yes
but that envolves also the namespace too
For example, a tuner is currently represented by: MEDIA_ENT_T_V4L2_SUBDEV_TUNER
but the tuner entity can be used alone on a pure DVB device
(or eventually by some other subsystem like net/wireless?)
IMHO, what's there right now under MEDIA_ENT_T_V4L2_SUBDEV_* namespace range is messy
as the namespace is mixing a device node (V4L2_SUBDEV) - that we've remapped as interfaces with entities
I mean: no hardware vendor ever designed a webcam sensor to be of the type "V4L2"
it should be just MEDIA_ENT_T_SENSOR
and not MEDIA_ENT_T_V4L2_SUBDEV_SENSOR
Wednesday should work
ok, so let's do it on Wed. What time works best?
hverkuil: I see. I also had a question about support for the newer Hauppauge "WinTV-HVR-2255" (modified version of the "WinTV-HVR-2250" released about 1 year ago).
I have a wintv-hvr-2255 and I realize that ATSC support for this card merged into the mainline kernel, but since the card is currently installed on an ubuntu 15.04 (vivid) system that needs to run 24/7, I do not have the option of compiling the new kernel with the new kernel modules (even if I was successful in doing so) to make the card work since I cannot reboot the machine to load the new kernel.
So, I was wondering if anybody has pre-compiled binaries of the "WinTV-HVR-2255" kernel modules for kernel version '3.19.0-15-generic' (default kernel used by ubuntu vivid), and if so, where can I download them from?
and since the ubuntu 15.04 kernel ('3.19.0-15-generic') does not have support this card yet (support was merged into the mainline kernel only about 2-3 months ago IINM).
and I know that Hauppauge has also posted patches for Ubuntu 14.04 (http://hauppauge.lightpath.net/software/linux/linux-ubuntu-14-04-2.tar.xz), but I do not have the technical know-how to port those patches to kernel '3.19.0-15-generic'.
I'm not aware of precompiled binaries.
but if it has to run 24/7 I wouldn't use those anyway. Bad idea to experiment with that on a production system.
You can use this: http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers
but the same problem remains that it is dangerous to experiment with that on a running system.
mchehab: I have nothing scheduled for Wednesday, so it can be any time. But all things being equal I would prefer the discussion for the afternoon (after 2pm, UTC+2)
thanks - that is good to know. with my risk-taking personality and my despertion to get the card to work, I would have tried to compile the modules and force-load them. but if that has the high risk of kernel panic and/or other crash, I will not try that, since the system does need to run 24/7, and I would loose all unsaved data in addition to the downtime.
But are PCIe (PCI Express) cards hot-pluggable? That is can I safely remove one card (for example, the "WinTV-HVR-2255" card) and insert another card on a system running GNU/Linux?
while the system is running i mean.
Depends on the PCIe chipset. I never dared removing a PCIe card when the system is running.
Frankly, unless you have an identical system that is not mission-critical and that you can use for testing things like this first, I wouldn't take the risk.
mchehab: do you want us to start looking at patch v8 series. I haven't had a chance to catch up with patch v7 yet :)
I see. yeah, that probably is too risky.
v8 is basically bug fixes, plus some additional patches from Javier
and I merged 3 patches I send on last Monday at the end
shuah: I found v8 easier to review than v7.
because it contains those 3 patches from Monday and Javier's patches.
hverkuil: thanks for the tip - Monday blues and felt overwhelmed seeing a 55 patch series
hverkuil: that's exactly my poing with big patch series
read my comments as well before doing your own review so you don't have to look at things I already did.
s/poing/point/
mchehab: it still has to be reviewed :-) It doesn't matter how you organize it.
sure
Obviously I am skipping patches that had my Ack already.
sure
yeah, that helps reviewers
hverkuil: just added support for connectors... see if you think this is ok: https://mchehab.fedorapeople.org/mc-next-gen/au0828.png
(patches still on my local machine)
the graph is the real one, produced by mc_nextgen_test tool
I hacked the driver to have only 5 outputs for the demux (driver uses 256 outputs) and to have a subdev for tuner, just to be able to test everything with a single device
gah, dvb pad got wrong
I mean, the link between tuner and dvb demod
we really need a better way to find the right pads
than just using a magic number
hverkuil, pinchartl: confirmed. we'll have the Media workshop there at the Kernel Summit
Can someone point me in the right direction to create a sub device for a BT656 camera that is always on. The camera is always on as soon as power is applied, so I am guessing that I will need ot make a dummy driver and then register the sub device with the DM365 vpfe capture driver to capture the video. Any help would be greatly appreciated.
mchehab: when is the media summit - which day during the KS week
not sure. should check at the KS ML
I'll check and send an email to media ML later
ok thanks
hello, I would like to know what is the best quality PCI (not PCIe) ATSC tuner/recorder card that there is, the one that got all the best professional/editor/customer reviews for ATSC/digital recording when PCI was standard.