t;$ xrandr --addmode VGA-1 1680x1050_60.00 $ xrandr --output VGA-1 --mode
>1680x1050_60.00
>I'm also curious about why that is 1728. Actually, this workaround was
>provided from the chip vendor, Aspeed, and they use this in their SDK code
>too. Let's check it to Ryan.
>Hi
. Product image Retouching
. Wedding & Event Album Design.
. Portrait image Retouching
We give you editing test on your photos.
Thanks,
Julie Ryan
. Product image Retouching
. Wedding & Event Album Design.
. Portrait image Retouching
We give you editing test on your photos.
Thanks,
Julie Ryan
to be able to display on the LCD.
thanks for your help.
Thanks,
ryan
Hi Laurent,
Apologies for my late reply.
[...]
>
> > I searched here for some time before posting and haven't found the
> > answer as of yet. Perhaps my search'foo isn't really there and to tell
> > you the truth cameras and what not are a weak spot for me. Never
> > really cared about them unt
Hi Laurent,
Thanks again for your reply.
On 03/04/2014 12:11 PM, Laurent Pinchart wrote:
Hi Mark,
On Friday 28 February 2014 10:34:24 Mark Ryan wrote:
On 02/26/2014 04:40 PM, Laurent Pinchart wrote:
[ ... ]
With the information I've given you, could you try to log more information
i
Hi Laurent,
On 02/26/2014 04:40 PM, Laurent Pinchart wrote:
Hi Mark,
[ ... ]
With the information I've given you, could you try to log more information in
the driver to try and find what goes wrong ? You could for instance log the
content of each header at the beginning of the uvc_video_de
Hi Laurent,
Thank you so much for your detailed response.
On 02/26/2014 04:40 PM, Laurent Pinchart wrote:
Hi Mark,
On Wednesday 26 February 2014 10:20:06 Ryan, Mark D wrote:
On Tuesday, February 25, 2014 10:50 PM Sarah Sharp wrote:
Hi Laurent and Mauro,
Mark has running into issues with
> -Original Message-
> From: Sharp, Sarah A
> Sent: Tuesday, February 25, 2014 10:50 PM
> To: Laurent Pinchart; Mauro Carvalho Chehab
> Cc: linux-media@vger.kernel.org; Ryan, Mark D
> Subject: Dell XPS 12 USB camera bulk mode issues
>
> Hi Laurent and Mauro,
&g
On 08/10/12 16:05, Julia Lawall wrote:
> On Mon, 8 Oct 2012, Ryan Mallon wrote:
>
>> On 08/10/12 02:38, Julia Lawall wrote:
>>> From: Julia Lawall
>>>
>>> Introduce use of I2c_MSG_READ/WRITE/OP, for readability.
>>>
>>> A length expresse
st of the cases where 2 messages are used, the first message
> has length equal
> to one, and it uses a fixed u8 constant with the I2C sub-address. So, maybe
> it would be nice
> to have a variant for this case.
That ends up with a whole bunch of variants of the macro for something
which should be very simple. The proposal has three macros, and the
I2C_MSG_OP macro is only required for a one or two corner cases where
non-standard flags are used.
~Ryan
--
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
ne here or as a separate
patch. Some of the other patches also have cases where single index
arrays (both buffers and messages) could be converted. Should either
convert all or none of them. I think its probably best to do as a
separate series on top of this though.
~Ryan
>
> ret =
if (i2c_transfer(priv->i2c_props.adap, &msg, 1) != 1) {
> if (priv->ignore_i2c_write_errors == 0) {
> printk(KERN_ERR "xc4000: I2C write failed (len=%i)\n",
> @@ -550,10 +549,8 @@ static int xc4000_readreg(struct xc4000_priv *priv, u16
> reg, u16 *val)
> u8 buf[2] = { reg >> 8, reg & 0xff };
> u8 bval[2] = { 0, 0 };
> struct i2c_msg msg[2] = {
> - { .addr = priv->i2c_props.addr,
> - .flags = 0, .buf = &buf[0], .len = 2 },
> - { .addr = priv->i2c_props.addr,
> - .flags = I2C_M_RD, .buf = &bval[0], .len = 2 },
> + I2C_MSG_WRITE(priv->i2c_props.addr, &buf[0], sizeof(buf)),
> + I2C_MSG_READ(priv->i2c_props.addr, &bval[0], sizeof(bval)),
&buf[0] == buf. Might as well fix this now, the way it is written is
just silly.
> };
>
> if (i2c_transfer(priv->i2c_props.adap, msg, 2) != 2) {
> diff --git a/drivers/media/tuners/xc5000.c b/drivers/media/tuners/xc5000.c
> index dc93cf3..33b6b1e 100644
> --- a/drivers/media/tuners/xc5000.c
> +++ b/drivers/media/tuners/xc5000.c
> @@ -253,8 +253,7 @@ static int xc5000_TunerReset(struct dvb_frontend *fe);
>
> static int xc_send_i2c_data(struct xc5000_priv *priv, u8 *buf, int len)
> {
> - struct i2c_msg msg = { .addr = priv->i2c_props.addr,
> -.flags = 0, .buf = buf, .len = len };
> + struct i2c_msg msg = I2C_MSG_WRITE(priv->i2c_props.addr, buf, len);
>
> if (i2c_transfer(priv->i2c_props.adap, &msg, 1) != 1) {
> printk(KERN_ERR "xc5000: I2C write failed (len=%i)\n", len);
> @@ -285,10 +284,8 @@ static int xc5000_readreg(struct xc5000_priv *priv, u16
> reg, u16 *val)
> u8 buf[2] = { reg >> 8, reg & 0xff };
> u8 bval[2] = { 0, 0 };
> struct i2c_msg msg[2] = {
> - { .addr = priv->i2c_props.addr,
> - .flags = 0, .buf = &buf[0], .len = 2 },
> - { .addr = priv->i2c_props.addr,
> - .flags = I2C_M_RD, .buf = &bval[0], .len = 2 },
> + I2C_MSG_WRITE(priv->i2c_props.addr, &buf[0], sizeof(buf)),
> + I2C_MSG_READ(priv->i2c_props.addr, &bval[0], sizeof(bval)),
Same here, change &buf[0] to buf.
> };
>
> if (i2c_transfer(priv->i2c_props.adap, msg, 2) != 2) {
>
~Ryan
--
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
iv->cfg->i2c_address,
> - .flags = 0, .buf = ®, .len = 1 },
> - { .addr = priv->cfg->i2c_address,
> - .flags = I2C_M_RD, .buf = val, .len = 1 },
> + I2C_MSG_WRITE(priv->cfg->i2c_address, ®, sizeof(reg)),
> +
addr, buf, sizeof(buf))
>>> };
>>>
>>
>> Any reason why struct i2c_msg is an array ?
>
> I assumed that it looked more harmonious with the other uses of
> i2c_transfer, which takes as arguments an array and the number of elements.
>
> But there are some files that instead use i2c_transfer(priv->i2c, &msg, 1).
> I can change them all to do that if that is preferred. But maybe I will
> wait a little bit to see if there are other issues to address at the
> same time.
This is probably a good thing to do, but the initial patch series should
just do the conversion to the macros. Too many additional changes runs
the risk of introducing bugs and making bisection difficult.
~Ryan
--
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
macros are like the macros PCI_DEVICE and PCI_DEVICE_CLASS.
>
> I understand that.
>
>> Are READ and WRITE the action names? They are really the important
>> information in this case.
>
> Yes, most (all?) uses of _READ and _WRITE macros actually
> perform some I/O.
W
Hi,
Is there an V4L Port in the camera hal implementations on android ice
cream sandwich which makes use
of panda v4l camera drivers.
Thanks & Regards,
Ryan
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.k
Hi Sergio,
On Mon, Feb 20, 2012 at 10:33 AM, Aguirre, Sergio wrote:
> H Ryan,
>
> On Sun, Feb 19, 2012 at 10:04 AM, Ryan wrote:
>> Hi Laurent,
>>
>> It actually blocks at VIDIOC_DQBUF ioctl and not in STREAMON ioctl.
>> Looks like the data is not available.
>
Hi Laurent,
It actually blocks at VIDIOC_DQBUF ioctl and not in STREAMON ioctl.
Looks like the data is not available.
Any way of verifying if OMAP is receiving data. Wonder why i keep
interrupts though?
Is my media-ctl setting up things correctly?
Thank you.
Regards,
Ryan
On Sun, Feb 19
Hi Laurent,
On Sun, Feb 19, 2012 at 2:27 PM, Laurent Pinchart
wrote:
> Hi Ryan,
>
> On Saturday 18 February 2012 20:59:57 Ryan wrote:
>> hello,
>> I am using media-ctl on the panda board. The sensor gets detected. But
>> media-ctl doesnt print anything.
>> The ke
Enumerating entities
Found 0 entities
Enumerating pads and links
Device topology
What steps i need to follow get output from sensor in terms of
arguments to media-ctl and yavta.
Regards,
ryan
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message
I originally fixed some bugs on the original lirc_mod_mce driver that
Jon Davies was hosting, but found myself without a working keyboard
after upgrading to Ubuntu Natty with the new ir-core. I just quckly
backported the ir-mce_kbd-decoder driver that Jarod Wilson posted a
while back for my Ubuntu
On 05/17/2011 08:59 PM, Wu, Josh wrote:
>
> On Friday, May 13, 2011 5:25 AM, Ryan Mallon wrote
>
>> On 05/12/2011 07:42 PM, Josh Wu wrote:
>>> This patch is to enable Atmel Image Sensor Interface (ISI) driver support.
>>> - Using soc-camera framework wi
it
> were, you'd have to revamp half of the kernel.
It should at least be consistent within a file, which it is not true in
this case. I think the preferred style is to have the variable on the left.
~Ryan
--
Bluewater Systems Ltd - ARM Technology Solution Centre
Ryan Mallon
osh,
Thansk for doing this. Overall the patch looks really good. A few
comments below.
~Ryan
>
> Signed-off-by: Josh Wu
> ---
> base on branch staging/for_v2.6.40
>
> arch/arm/mach-at91/include/mach/at91_isi.h | 454
> drivers/media/video/Kconfig
I have a WinTV 1200 card that has this exact issue. Have you made any new
discoveries or progress? Thanks.
--
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
Message Received: Jun 02 2010, 11:01 AM
From: "john ryan"
To: linux-media@vger.kernel.org
Cc:
Subject: DVB-T af9015 ("K world) device problem, only gets channels from one
multiplex
Hi,
I'm running:
System uname:
Linux-2.6.32-g
Hello,
I use MT9T-111 camera sensor module. Is anyone working on this sensor?
Does an Open source driver available for this sensor.
I tried to program this sensor. There are nearly 200 registers and
looks like i keep missing some settings.
Thank you,
Regards,
ryan
--
To unsubscribe
Guennadi Liakhovetski wrote:
On Tue, 24 Nov 2009, Ryan Raasch wrote:
Hello,
I have implemented a driver for the LZ0P374 Sharp CCD camera sensor. I have
been using an old kernel, and now i am updating to the new soc_camera
framework. My question is, is there anyone using this sensor? We
Ryan Raasch wrote:
Carlos Lavin wrote:
i am asking that if it is possible to start a module without
MODULE_INIT function in the body of program.
It looks as though all drivers that use v4l2_i2c_driver_data DO NOT use
the module_init function.
According to commit
?
Cheers,
Ryan
--
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
,
v4l2_subdev is used instead. However, this is different for me also.
Ryan
2009/11/11 Ryan Raasch <mailto:ryan.raa...@gmail.com>>
Carlos Lavin wrote:
i don't know that it pass with this module, ov7670.c , because i
don't see
in the screen of my
I am trying to use a DVBWorld DVB-S 2102 USB2.0 device for multicast
data reception from EUMetCast. I have compiled the latest drivers from
Mecurial, and I can't seem to get the network device of the card to
work properly to setup reception for data via multiple channels.
[ 1148.757716] dvb-usb:
line away
from live streaming :)
Thanks,
Ryan
Dongsoo, Nathaniel Kim wrote:
On Wed, Aug 12, 2009 at 5:56 PM, Ryan Raasch wrote:
Thanks for the reply!
Dongsoo, Nathaniel Kim wrote:
On Wed, Aug 12, 2009 at 5:25 PM, Ryan Raasch wrote:
Hello,
I am trying to write a driver for a camera using
Thanks for the reply!
Dongsoo, Nathaniel Kim wrote:
On Wed, Aug 12, 2009 at 5:25 PM, Ryan Raasch wrote:
Hello,
I am trying to write a driver for a camera using the new soc_camera in the
mainline kernel the output is the overlay framebuffer (pxa270) and i would
like to use the overlay output
35 matches
Mail list logo
