A very minor point, but I've found some then/than confusion:
746: V4L2_LOG_ERR("attempting to open more then %d video devices\n", //
should be than
1038: V4L2_LOG_ERR("set_fmt gave us a different result then try_fmt!\n"); //
should be than
1318: /* No more buffers then we can manage please
On Thu, Feb 07, 2019 at 10:26:52PM +, Jason Gunthorpe wrote:
> Commit 2db76d7c3c6d ("lib/scatterlist: sg_page_iter: support sg lists w/o
> backing pages") introduced the sg_page_iter_dma_address() function without
> providing a way to use it in the general case. If the
On Thu, Feb 07, 2019 at 03:26:47PM -0700, Jason Gunthorpe wrote:
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> index 31786b200afc47..e84f6aaee778f0 100644
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> @@ -311,7 +3
st
wrongly mixing accessors and iterators.
Acked-by: Christoph Hellwig (for scatterlist)
Signed-off-by: Jason Gunthorpe
---
.clang-format | 1 +
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 8 +++-
drivers/media/pci/intel/ipu3/ipu3-cio2.c | 4 +-
include/linux/sca
On Thu, Jan 17, 2019 at 10:30:01AM +0100, h...@lst.de wrote:
> On Wed, Jan 16, 2019 at 10:24:36AM -0700, Jason Gunthorpe wrote:
> > The fact is there is 0 industry interest in using RDMA on platforms
> > that can't do HW DMA cache coherency - the kernel syscalls required
On Wed, Jan 16, 2019 at 05:11:34PM +0100, h...@lst.de wrote:
> On Tue, Jan 15, 2019 at 02:25:01PM -0700, Jason Gunthorpe wrote:
> > RDMA needs something similar as well, in this case drivers take a
> > struct page * from get_user_pages() and need to have the DMA map fail
> >
On Tue, Jan 15, 2019 at 02:17:26PM +, Thomas Hellstrom wrote:
> Hi, Christoph,
>
> On Mon, 2019-01-14 at 10:48 +0100, Christoph Hellwig wrote:
> > On Thu, Jan 10, 2019 at 04:42:18PM -0700, Jason Gunthorpe wrote:
> > > > Changes since the RFC:
> > > > -
On Sat, Jan 12, 2019 at 01:03:05PM -0600, Shiraz Saleem wrote:
> On Sat, Jan 12, 2019 at 06:37:58PM +0000, Jason Gunthorpe wrote:
> > On Sat, Jan 12, 2019 at 12:27:05PM -0600, Shiraz Saleem wrote:
> > > On Fri, Jan 04, 2019 at 10:35:43PM +, Jason Gunthorpe wrote:
> >
On Sat, Jan 12, 2019 at 12:27:05PM -0600, Shiraz Saleem wrote:
> On Fri, Jan 04, 2019 at 10:35:43PM +0000, Jason Gunthorpe wrote:
> > Commit 2db76d7c3c6d ("lib/scatterlist: sg_page_iter: support sg lists w/o
> > backing pages") introduced the sg_page_iter_dma_a
On Fri, Jan 04, 2019 at 03:35:31PM -0700, Jason Gunthorpe wrote:
> Commit 2db76d7c3c6d ("lib/scatterlist: sg_page_iter: support sg lists w/o
> backing pages") introduced the sg_page_iter_dma_address() function without
> providing a way to use it in the general case. If th
On Sat, Jan 05, 2019 at 10:37:17AM +0800, kbuild test robot wrote:
> Hi Jason,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on linus/master]
> [also build test ERROR on v4.20 next-20190103]
> [if your patch is applied to the wrong git tree, ple
gly
mixing accessors and iterators.
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h| 26 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_mob.c| 26 +++-
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 42 +--
drivers/media/pci/intel/ipu3/i
editors in house and daily basis 700 images can be done.
We can give testing for your photos if you send us one or two to start
working.
Thanks,
Jason Jones
editors in house and daily basis 700 images can be done.
We can give testing for your photos if you send us one or two to start
working.
Thanks,
Jason Jones
Do you have photos for cutting out,or adding clipping path?
We are here to help you for that also including retouching.
Both for product photos and portrait photos.
Yours,
Jason
Do you have photos for cutting out,or adding clipping path?
We are here to help you for that also including retouching.
Both for product photos and portrait photos.
Yours,
Jason
your photos,
You can throw us a photo and we will do testing for you to check our
quality.
Thanks,
Jason
your photos,
You can throw us a photo and we will do testing for you to check our
quality.
Thanks,
Jason
your photos,
You can throw us a photo and we will do testing for you to check our
quality.
Thanks,
Jason
esstable-perl (apt-get
install libproc-processtable-perl).
Cheers.
Jason.
On Thu, Apr 27, 2017 at 05:03:45PM -0600, Logan Gunthorpe wrote:
>
>
> On 27/04/17 04:11 PM, Jason Gunthorpe wrote:
> > On Thu, Apr 27, 2017 at 03:53:37PM -0600, Logan Gunthorpe wrote:
> > Well, that is in the current form, with more users it would make sense
> > to o
On Thu, Apr 27, 2017 at 03:53:37PM -0600, Logan Gunthorpe wrote:
> On 27/04/17 02:53 PM, Jason Gunthorpe wrote:
> > blkfront is one of the drivers I looked at, and it appears to only be
> > memcpying with the bvec_data pointer, so I wonder why it does not use
> > sg_
> this could be converted to use the sg_miter interface but that's a much
> more invasive change that would require someone who knows this code and
> can properly test it. I'd be very grateful if someone actually took that on.
blkfront is one of the drivers I looked at, and it appears to only be
memcpying with the bvec_data pointer, so I wonder why it does not use
sg_copy_X_buffer instead..
Jason
metimes a little bit more
convoluted..
Switching all the trivial cases to use copy might bring more clarity
as to what is actually required for the remaining few users? If there
are only a few then it may no longer matter if the API is not idyllic.
Jason
d by iopmem).
> So i say let solve the IOMMU issue first and let everyone use it in their
> own way with their device. I do not think we can share much more than
> that.
Solve it for the easy ZONE_DIRECT/etc case then.
Jason
--
To unsubscribe from this list: send the line "unsubsc
On Fri, Jan 06, 2017 at 12:37:22PM -0500, Jerome Glisse wrote:
> On Fri, Jan 06, 2017 at 11:56:30AM -0500, Serguei Sagalovitch wrote:
> > On 2017-01-05 08:58 PM, Jerome Glisse wrote:
> > > On Thu, Jan 05, 2017 at 05:30:34PM -0700, Jason Gunthorpe wrote:
> > > > On T
> So, how do you identify these GPU objects? How do you expect RDMA
> > convert them to scatter lists? How will ODP work?
>
> No ODP on those. If you want vma, the GPU device driver can provide
You said you needed invalidate, that has to be done via ODP.
Jason
--
To unsubscr
patches is totally
> > crazy and shouldn't be in mainline. Use ODP capable RDMA hardware.
>
> Well there is still a large base of hardware that do not have such
> feature and some people would like to be able to keep using those.
Hopefully someone will figure out how to do th
ay in RDMA. Async RDMA MR
Invalidate like you see in the above out of tree patches is totally
crazy and shouldn't be in mainline. Use ODP capable RDMA hardware.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord..
o create an entirely new
non-VMA based memory handle scheme for RDMA.
So my inclination is to just completely push back on this idea. You
need a VMA to do RMA.
GPUs need to create VMAs for the memory they want to RDMA from, even
if the VMA handle just causes SIGBUS for any CPU access.
Jason
--
T
On Tue, Dec 06, 2016 at 09:51:15AM -0700, Logan Gunthorpe wrote:
> Hey,
>
> On 06/12/16 09:38 AM, Jason Gunthorpe wrote:
> >>> I'm not opposed to mapping /dev/nvmeX. However, the lookup is trivial
> >>> to accomplish in sysfs through /sys/dev/char to find
s) will appear under the "dax" sub-directory.
>
> Personally I think mapping the dax resource in the sysfs tree is a nice
> way to do this and a bit more intuitive than mapping a /dev/nvmeX.
It is still not at all clear to me what userpsace is supposed to do
with this on nvme.. Ho
On Mon, Dec 05, 2016 at 12:27:20PM -0700, Logan Gunthorpe wrote:
>
>
> On 05/12/16 12:14 PM, Jason Gunthorpe wrote:
> >But CMB sounds much more like the GPU case where there is a
> >specialized allocator handing out the BAR to consumers, so I'm not
> >sure a gen
-dax instance corresponds to which nvme drive.
>
> I'm not opposed to mapping /dev/nvmeX. However, the lookup is trivial
> to accomplish in sysfs through /sys/dev/char to find the sysfs path
> of
But CMB sounds much more like the GPU case where there is a
specialized allocator ha
t is a good point about devm_memremap_pages limitations, but maybe
that just says to create a /sys/.../resource_dmableX ?
Or is there some reason why people want a filesystem on top of BAR
memory? That does not seem to have been covered yet..
Jason
--
To unsubscribe from this list: send the line &
re is pretty clear we the DMA API needs to be updated to
support that use and work can be done to solve the various problems
there on the basis of using ZONE_DEVICE pages to figure out to the
PCI-E end points
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-media
s and other things people seem to want to do on these
pages. Maybe the loose 'struct page' flow is not for those users.
But I think if you want kGPU or similar then you probably need vmaps
or something similar to represent the GPU pages in kernel memory.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
save system stability then kill the impacted
process, that will release the MRs.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
need both eventually, and I hope the
> infrastructure can be shared to some degree.
What use case do you see for in kernel?
Presumably in-kernel could use a vmap or something and the same basic
flow?
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
rnel p2p,
everything proposed so far is being mediated by a userspace VMA, so
I'd focus on making that work.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
are
constraints
This doesn't have to be faulting, but really anything that lets you
pause the GPU DMA and reload the page tables.
You might look at trying to use the IOMMU and/or PCI ATS in very new
hardware. IIRC the physical IOMMU hardware can do the fault and fence
and block stuff, but
I is mainly handle based
> so there is no need for CPU access by default.
You mean no need for the memory to be virtually mapped into the
process?
Do you expect to RDMA from this kind of API? How will that work?
Jason
--
To unsubscribe from this list: send the line "unsubscribe l
short
lived MRs or ODP MRs when working with scenarios that need FS
relocation?
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Nov 25, 2016 at 12:16:30PM -0500, Serguei Sagalovitch wrote:
> b) Allocation may not have CPU address at all - only GPU one.
But you don't expect RDMA to work in the case, right?
GPU people need to stop doing this windowed memory stuff :)
Jason
--
To unsubscribe from this li
27;m hearing most people say ZONE_DEVICE is the way to handle this,
which means the missing remaing piece for RDMA is some kind of DMA
core support for p2p address translation..
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Nov 23, 2016 at 06:25:21PM -0700, Logan Gunthorpe wrote:
>
>
> On 23/11/16 02:55 PM, Jason Gunthorpe wrote:
> >>> Only ODP hardware allows changing the DMA address on the fly, and it
> >>> works at the page table level. We do not need special handling for
On Thu, Nov 24, 2016 at 10:45:18AM +0100, Christian König wrote:
> Am 24.11.2016 um 00:25 schrieb Jason Gunthorpe:
> >There is certainly nothing about the hardware that cares
> >about ZONE_DEVICE vs System memory.
> Well that is clearly not so simple. When your ZONE_DEVICE page
will not solve RDMA MR issue where "lock"
> could be during the whole application life but (a) it will not make
> RDMA MR case worse (b) should be enough for all other cases for
> "get_user_pages"/"put_page" controlled by kernel.
Right. There is no s
eed to use page
table mirroring for this.
ODP comes in when userpsace mmaps a DAX file and then tries to use it
for RDMA. Page table mirroring lets the DAX filesystem decide to move
the backing pages at any time. When it wants to do that it interacts
with the MM in the usual way which links to ODP
user-space while inside the kernel it's ZONE_DEVICE.
Seems fine for RDMA?
Didn't we just strike off everything on the list except #2? :\
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
s
what ODP does.
Like I said, this is the direction the industry seems to be moving in,
so any solution here should focus on VMAs/page tables as the way to link
the peer-peer devices.
To me this means at least items #1 and #3 should be removed from
Alexander's list.
Jason
--
To unsubscribe f
On Wed, Nov 23, 2016 at 02:14:40PM -0500, Serguei Sagalovitch wrote:
>
> On 2016-11-23 02:05 PM, Jason Gunthorpe wrote:
> >As Bart says, it would be best to be combined with something like
> >Mellanox's ODP MRs, which allows a page to be evicted and then trigger
> &g
ory is. ODP is just a generic
mechanism to provide demand-fault behavior for a mirrored page table.
ODP has the same issue as everything else, it needs to translate a
page table entry into a DMA address, and we have no API to do that
when the page table points to peer-peer memory.
Jason
--
To unsubsc
that are mirroring translation tables?
>From a RDMA perspective we could use something other than
get_user_pages() to pin and DMA translate a VMA if the core community
could decide on an API. eg get_user_dma_sg() would probably be quite
usable.
Jason
--
To unsubscribe from this list: send the line &
out of this driver
too. PPC never had HTX.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Apr 22, 2015 at 05:23:28PM +0200, Luis R. Rodriguez wrote:
> On Tue, Apr 21, 2015 at 11:39:39PM -0600, Jason Gunthorpe wrote:
> > On Wed, Apr 22, 2015 at 01:39:07AM +0200, Luis R. Rodriguez wrote:
> > > > Mike, do you think the time is right to just re
gt; they likely had PAT support, when upgrading kernels PAT will work
> but write-combing won't on ipath.
Sorry, do you mean the driver already doesn't get WC? Or do you mean
after some more pending patches are applied?
Jason
--
To unsubscribe from this list: send the line "unsubscr
ance to
the point the driver is unusable. If we drop MTRR we may as well
remove the driver.
Mike, do you think the time is right to just remove the iPath driver?
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vge
Jason Millar
European Purchasing
01257795272
www.douglasvalley.co.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
determine which chip is used in the camera so I can try doing
so again?
-Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Am 09.02.2012 22:12, schrieb Torfinn Ingolfsen:
Update:
On Thu, Feb 9, 2012 at 12:04 AM, Torfinn Ingolfsen wrote:
Never mind. after adding this patch:
http://patchwork.linuxtv.org/patch/9691/
and rebuilding the media drivers, the device is now detected:
tingo@kg-f4:~$ dmesg | grep -i terratec
>> latest news on that seems to be that you were working on cleaning up
>> the code of the Realtek-provided GPL driver, with the goal of
>> eventually getting it into mainline.
Ah, does the Realtek branch have support for DAB(+) and FM? In
Windows the chip can do DAB+ and FM as well as DVB-T. Th
I concur. I have been using Malcolm Priestly's patches with both my
AF9015 dual tuner cards (which are PCI but still look like USB to the
kernel) for a few weeks now and have (finally!) got consistently
perfect recordings in MythTV simultaneously with both tuners on a
card. Malcolm, when do you th
n v4l related
patch has affected us all.
> I am continuing to look into it.
OK, well I am still running my system with your two patches, with
corruptions alas, so if you'd like me to independently try stuff out
let me know.
Jason
--
To unsubscribe from this list: send the line "unsu
ng to the
> devices.
Great. If you want I can replicate your tests here to see what I get.
Antti, my AF9015 chips are integrated on PCI so I can't swap cables
(alas, if only this was my problem!)
Cheers
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-media"
> Which kernels are you all running?
2.6.38-11-generic #50-Ubuntu SMP (Mythbuntu 11.04)
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
> Try this patch, it should stop start up corruption on the same frontend.
Thanks. I'll try it today.
Have you been able to reproduce any of the corruption issues I and
others are having?
I noticed last night some recordings on the same card had different
levels of corruption depending on the o
and maybe disable USB
sleeping/powerdown.
Someone on another mailing list is having similar problems in
Windows(!) and found the errors were minimal if PCI latency was set to
96.
I am beginning to think Afatech is just crappy.
Jason
--
To unsubscribe from this list: send the line "unsubscribe l
> http://dl.dropbox.com/u/1541853/VID_20111006_004447.3gp
That looks very familiar! Does it occur on tuner A or B?
> I get this I2C messages:
> # tail -f /var/log/messages
> Oct 5 20:16:44 htpc kernel: [ 534.168957] af9013: I2C read failed reg:d330
As far as I know I never had any such messag
> http://palosaari.fi/linux/v4l-dvb/firmware/af9015/5.1.0.0/dvb-usb-af9015.fw
5.1? OK, I might eventually try that one too.
> This morning I get a little pixeled playback, less than a second.
OK, mine was fine for a few days then the pixellation started up in earnest.
At the moment my symptoms
> Which Firmware are your using?
4.95
> Yes, because it is also happening with other duo devices on Myth TV
> 0.24.1
OK, well that is what I am using so I guess I am stuck until it's fixed.
Josu what software and versions are you using?
--
To unsubscribe from this list: send the line "unsubscri
I have had some luck with this patch. I am still getting fouled
recordings with tuner A but it's not consistent. I have yet to
ascertain if the problem occurs depending on the order of tuning to
have both tuners recording different frquencies at the same time, ie
Tuner B then Tuner A or vice vers
> I think what might happening is that TS packets are getting chopped, as
> device seems to want
> to align to max packet size.
Oh, I also noticed that the Linux driver uses a smaller USB packet
count than Windows. Is there any discernible reason for this? Lag on
DVB isn't an issue for me and p
Damn, this patch didn't help so maybe forget this patch. Tuner A is
still messed up.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
I might have found one bug so far with the Afa9013 driver.
As part of refactoring the code in
http://git.linuxtv.org/linux-2.6.git/commitdiff/edb709b61abd3ba475e59d1ad81aab21ad025db6
I think one of the u32->u8 calculations is wrong.
The think the second last u32 in the tables has to be changed. H
I just tried LiveCDs of Mythbuntu 10.04 and 10.10 but had limited luck
with the former and some joy with the latter. Unfortunately the
default framebuffer slowed things down. Anyway in LiveCD 10.10 I used
mplayer to set up and view Tuner A and Tuner B and Tuner A only showed
some slight errors wh
I have a problem that may be related to the issues on this thread and
it's driving me nuts.
I have two dual tuner Afatech based cards, they are both Leadtek
2000DS cards, one made by Leadtek and the other branded as KWorld but
they are otherwise identical in spite of different VID:PID.
On each ca
out of 2.6.38. This one
compiled cleanly into the tree, and worked perfectly.
Thanks for pointing it out.
Jason
failed: SEND_ONCE blaster 0_74_KEY_2
irsend: hardware does not support sending
First one worked. Second does not.
Thanks,
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
All,
>Okay, so I emailed a little too quickly. The messages above got me thinking.
>One of them is successful the other is not.
>I verified with irsend. So, this may be an issue with multiple hdpvrs.
I believe I've tracked this down.
In lirc_zilog.c:
At 1307:
ret = add_i
>Admittedly, I do not understand exactly what I am reading. It seems to probe
>the IR Tx (i2c-1) successfully:
>May 21 12:51:06 jgauthier-mythtv kernel: [ 43.088265] lirc_zilog: probe of
>IR Tx on Hauppage HD PVR I2C (i2c-1) done. IR unit ready.
>But, then below on (i2c-2) is failed:
>May 21
zilog)
against it, (I read it somewhere) but that did not really make a difference.
Thanks,
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
y and I am
merely a Linux enthusiast/user (not a programmer) - so apologies if I
have taken the wrong tact for such a request.
Appreciate any help.
Jason
Two patch files I use ...
# v4l-dvb-saa7164.patch
diff -crB v4l-dvb/linux/drivers/media/video/saa7164/saa7164-cards.c
v4
saver to
have all DVB cards initialised in parallel to speed up booting of a
system.
I have reverted back to Mythbuntu 10.04 and kernel 2.6.32 and the
cards work fine now (though with the latest v29 of the firmware for
these cards).
Cheers
Jason
--
To unsubscribe from this list: send the line
> B) Use of V4L2 as a frontend for SW/DSP codecs
> (Laurent)
This would be good. Realtek's RT2832U chip can tune to and possibly
demodulate DAB/DAB+ and FM along with the usual DVB-T. Realtek does
support DAB and FM in Windows with this part but not in Linux and in
spite of promises from one
I seem to have fixed the problem for now. It's the hoary old problem
of Mythtv's backend coming up and accessing the cards before the
firmware has loaded onto the cards. Adding in a startup delay to
myth-backend's init script has solved the problem, for now. The
firmware seems to load now on Myt
I'll add the following kernel debug info for what it's worth:
-
Mar 12 11:22:51 mythtv kernel: [ 14.025097] saa7130/34: v4l2 driver
version 0.2.16 loaded
Mar 12 11:22:51 mythtv kernel: [ 14.026609] saa7134 :00:09.0:
PCI INT A -> GSI 17 (level, low) -> IRQ 17
Mar 12 11:22:51 mythtv kern
I just bought a pair of what are a version of the My Cinema 7131 Hybrid cards.
The kernel reports it as saa7134: Asus Tiger revision 1.0, subsys 1043:4857
I did inititially try Mythbuntu 10.04 but the firmware upload seemed
to fail fairly consistently. Restarting with v10.10 the firmware
loads b
>> I've got two hdpvrs. Whenever you're ready to extend your testing,
>> I'm happy to extend that functional testing. I didn't get a chance to
>> look at the FC14 patch yet (busy couple of days), but I will hold off
>> now, anyway!
>If all goes well, with Jarrod's change, you should be able to
>>
>> Bah. Yeah, sorry, that wasn't the current patch in Fedora 14. This is:
>>
>> http://wilsonet.com/jarod/lirc_misc/hdpvr-ir/hdpvr-ir-enable-2.patch
>>
>> Its atop the F14 2.6.35.10 kernel, which has a fairly recent v4l/dvb
>> backport on top of it, so it should be pretty close to matching t
>>
>> I did simply try changing:
>>
>> /* until i2c is working properly */
>> retval = 0; /* hdpvr_register_i2c_ir(dev); */
>> if (retval < 0)
>>
>> so that it would register with i2c.
>> Doing so returns a positive registration with I2C, but the lirc_zilog
>> driver doesn't s
e lirc_zilog is now in the kernel, yay)
Really appreciate any help!
Thanks,
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, 2011-01-08 at 10:44 -0500, Jason Gauthier wrote:
>> Andy,
>>
>>Firstly, I apologize for reaching out to you directly.
>The list could have answered this, so I adding the Cc:.
At the time of my searches, and the results, it was not apparent to me there
;t sound too hard to do.
>
as for two endpoints, I've been playing with getting the code from
drivers/media/video/gspca/konica.c. into kinect.c. It enumerates
multiple URBs for one USB device. Perhaps a combination of the above
and the konica driver will work?
thx,
Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ide to stay with two video nodes, some udev magic could
create:
/dev/kinect/depth -> ../videoX
/dev/kinect/camera -> ../videoY
/dev/kinect/ir -> ../videoZ
...
For consistent naming.
thx,
Jason.
[1] http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome
--
To unsubscribe from this list: send
ill handle this address as an
non-DMA address and call dma_map_single/sg to map it. On arm
architecture, dma_map_single a DMA coherent address will be catched
by a BUG_ON().
Signed-off-by: Jason Wang
---
drivers/media/video/gspca/gspca.c |1 +
1 files changed, 1 insertions(+), 0 deleti
er Fedora on it with a kernel
that worked.
I did see another posting to this mail list from someone with the same
problem which I'll take as confirmation that it is not just me :)
Regards,
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
t
Thierry Merle wrote:
Jason Harvey wrote:
Thierry Merle wrote:
Hi Jason,
Jason Harvey wrote:
I have been successfully using VDR with two CinergyT2s for 18 months.
After adding a Hauppage NOVA-S2-HD I updated my v4l-dvb drivers hoping
to get S2 capability and test a newer VDR
Thierry Merle wrote:
Hi Jason,
Jason Harvey wrote:
I have been successfully using VDR with two CinergyT2s for 18 months.
After adding a Hauppage NOVA-S2-HD I updated my v4l-dvb drivers hoping
to get S2 capability and test a newer VDR for HD reception.
The CinergyT2s stopped working. The
10,
2.6.27.12-170.2.5.fc10.i686
I downloaded the current v4l-dvb today (31Jan2009) and tried it all
again before posting this message.
Not sure where to look next, I did start to capture the USB traffic to
see if I could spot the difference...
Thanks,
Jason
--
To unsubscribe from this list
1 - 100 of 102 matches
Mail list logo
