On 02/12/2013 11:45 PM, Stéphane Marchesin wrote:
- Do we need to support chaining several encoders ? We can come up with
> several theoretical use cases, some of them probably exist in real hardware,
> but the details are still a bit fuzzy.
So, a part which is completely omitted in this threa
On 02/12/2013 11:45 PM, St?phane Marchesin wrote:
>> - Do we need to support chaining several encoders ? We can come up with
>> > several theoretical use cases, some of them probably exist in real
>> > hardware,
>> > but the details are still a bit fuzzy.
> So, a part which is completely omitted
Den 12 feb 2013 23:02 skrev "Greg KH" :
>
> On Tue, Feb 12, 2013 at 04:04:53PM +0100, Marcus Lorentzon wrote:
> > 3) Daniel V hinted that multiple parents (or multiple busses) is
> > something that has been discussed as a limitation of device driver
> > model
On 02/12/2013 04:53 PM, Tomi Valkeinen wrote:
> On 2013-02-12 17:04, Marcus Lorentzon wrote:
>
>> Now we have some different types of panels which are attached on a
>> combination of busses:
>>
>> a) control:DBI, data:DBI
>> b) control:I2C/SPI, data:I2C/SPI
Hi Greg,
at FOSDEM we had a session on CDF (Common Display Framework). You can
read more details about this in the posts from Laurent Pinchart on dridevel:
http://lists.freedesktop.org/archives/dri-devel/2012-November/030888.html
http://lists.freedesktop.org/archives/dri-devel/2013-February/034576
Den 12 feb 2013 23:02 skrev "Greg KH" :
>
> On Tue, Feb 12, 2013 at 04:04:53PM +0100, Marcus Lorentzon wrote:
> > 3) Daniel V hinted that multiple parents (or multiple busses) is
> > something that has been discussed as a limitation of device driver
> > model
On 02/12/2013 04:53 PM, Tomi Valkeinen wrote:
On 2013-02-12 17:04, Marcus Lorentzon wrote:
Now we have some different types of panels which are attached on a
combination of busses:
a) control:DBI, data:DBI
b) control:I2C/SPI, data:I2C/SPI
c) control:static setup, data:DPI
d) control:I2C/SPI
Hi Greg,
at FOSDEM we had a session on CDF (Common Display Framework). You can
read more details about this in the posts from Laurent Pinchart on dridevel:
http://lists.freedesktop.org/archives/dri-devel/2012-November/030888.html
http://lists.freedesktop.org/archives/dri-devel/2013-February/0345
On 02/11/2013 09:21 AM, Tomi Valkeinen wrote:
> On 2013-02-08 16:54, Marcus Lorentzon wrote:
>> On 02/08/2013 03:02 PM, Tomi Valkeinen wrote:
>>> On 2013-02-08 15:28, Marcus Lorentzon wrote:
>>>
>>>> When we do that we stop->setup->start during blanki
On 02/11/2013 09:21 AM, Tomi Valkeinen wrote:
On 2013-02-08 16:54, Marcus Lorentzon wrote:
On 02/08/2013 03:02 PM, Tomi Valkeinen wrote:
On 2013-02-08 15:28, Marcus Lorentzon wrote:
When we do that we stop->setup->start during blanking. So our "DSS" is
optimized to be able to
On 02/08/2013 03:02 PM, Tomi Valkeinen wrote:
> On 2013-02-08 15:28, Marcus Lorentzon wrote:
>
>> When we do that we stop->setup->start during blanking. So our "DSS" is
>> optimized to be able to do that without getting blocked. All DSI video
>> mode panel
On 02/08/2013 02:04 PM, Tomi Valkeinen wrote:
> On 2013-02-08 14:40, Marcus Lorentzon wrote:
>
>> I agree, but I think it should be
>> setup->enable->video_on->video_off->disable->setup->...
>> I don't think there is any interface parameters that sho
On 02/08/2013 11:51 AM, Tomi Valkeinen wrote:
> On 2013-02-04 12:05, Marcus Lorentzon wrote:
>
>> As discussed at FOSDEM I will give DSI bus with full feature set a
>> try.
> Please do, but as a reminder I want to raise the issues I see with a DSI
> bus:
>
> - A dev
On 02/08/2013 12:40 PM, Tomi Valkeinen wrote:
> Hi,
>
> On 2013-02-03 21:17, Tomasz Figa wrote:
>> Hi Laurent,
>>
>> On Saturday 02 of February 2013 11:39:59 Laurent Pinchart wrote:
>>> Hi Tomasz,
>>>
>>> Thank you for your RFC.
>>>
>>> On Wednesday 30 January 2013 16:38:59 Tomasz Figa wrote:
On 02/08/2013 03:02 PM, Tomi Valkeinen wrote:
On 2013-02-08 15:28, Marcus Lorentzon wrote:
When we do that we stop->setup->start during blanking. So our "DSS" is
optimized to be able to do that without getting blocked. All DSI video
mode panels (and DPI) products we have done
On 02/08/2013 02:04 PM, Tomi Valkeinen wrote:
On 2013-02-08 14:40, Marcus Lorentzon wrote:
I agree, but I think it should be
setup->enable->video_on->video_off->disable->setup->...
I don't think there is any interface parameters that should be changed
while link is en
On 02/08/2013 11:51 AM, Tomi Valkeinen wrote:
On 2013-02-04 12:05, Marcus Lorentzon wrote:
As discussed at FOSDEM I will give DSI bus with full feature set a
try.
Please do, but as a reminder I want to raise the issues I see with a DSI
bus:
- A device can be a child of only one bus. So if
On 02/08/2013 12:40 PM, Tomi Valkeinen wrote:
Hi,
On 2013-02-03 21:17, Tomasz Figa wrote:
Hi Laurent,
On Saturday 02 of February 2013 11:39:59 Laurent Pinchart wrote:
Hi Tomasz,
Thank you for your RFC.
On Wednesday 30 January 2013 16:38:59 Tomasz Figa wrote:
Changes done to Tomi's edition
On 02/02/2013 12:35 AM, Laurent Pinchart wrote:
> Hi Marcus,
>
> On Tuesday 08 January 2013 18:08:19 Marcus Lorentzon wrote:
>> On 01/08/2013 05:36 PM, Tomasz Figa wrote:
>>> On Tuesday 08 of January 2013 11:12:26 Marcus Lorentzon wrote:
[...]
>>>> But it is not
On 02/02/2013 12:35 AM, Laurent Pinchart wrote:
Hi Marcus,
On Tuesday 08 January 2013 18:08:19 Marcus Lorentzon wrote:
On 01/08/2013 05:36 PM, Tomasz Figa wrote:
On Tuesday 08 of January 2013 11:12:26 Marcus Lorentzon wrote:
[...]
But it is not perfect. After a couple of products we
On 01/29/2013 04:50 PM, Daniel Vetter wrote:
> On Tue, Jan 29, 2013 at 3:19 PM, Daniel Vetter
> wrote:
> Ok, in the interest of pre-heating the discussion a bit I've written down
> my thoughts about display slave drivers. Adding a few more people and
> lists to make sure I haven't missed anyone .
On 01/29/2013 04:50 PM, Daniel Vetter wrote:
On Tue, Jan 29, 2013 at 3:19 PM, Daniel Vetter wrote:
Ok, in the interest of pre-heating the discussion a bit I've written down
my thoughts about display slave drivers. Adding a few more people and
lists to make sure I haven't missed anyone ...
Cheer
On 01/08/2013 05:36 PM, Tomasz Figa wrote:
> On Tuesday 08 of January 2013 11:12:26 Marcus Lorentzon wrote:
>> On 01/08/2013 09:18 AM, Laurent Pinchart wrote:
>>> On Thursday 27 December 2012 15:43:34 Tomasz Figa wrote:
>>>>> On Monday 24 of December 201
On 01/08/2013 09:18 AM, Laurent Pinchart wrote:
> On Thursday 27 December 2012 15:43:34 Tomasz Figa wrote:
>> > On Monday 24 of December 2012 15:12:28 Laurent Pinchart wrote:
>>> > > On Friday 21 December 2012 11:00:52 Tomasz Figa wrote:
> > > On Tuesday 18 of December 2012 08:31:30 Vika
On 01/08/2013 05:36 PM, Tomasz Figa wrote:
On Tuesday 08 of January 2013 11:12:26 Marcus Lorentzon wrote:
On 01/08/2013 09:18 AM, Laurent Pinchart wrote:
On Thursday 27 December 2012 15:43:34 Tomasz Figa wrote:
On Monday 24 of December 2012 15:12:28 Laurent Pinchart wrote:
> On Fri
On 01/08/2013 09:18 AM, Laurent Pinchart wrote:
On Thursday 27 December 2012 15:43:34 Tomasz Figa wrote:
> On Monday 24 of December 2012 15:12:28 Laurent Pinchart wrote:
> > On Friday 21 December 2012 11:00:52 Tomasz Figa wrote:
> > > On Tuesday 18 of December 2012 08:31:30 Vikas Sajjan
On 12/18/2012 06:04 AM, Dave Airlie wrote:
>> Many developers showed interest in the first RFC, and I've had the
>> opportunity
>> to discuss it with most of them. I would like to thank (in no particular
>> order) Tomi Valkeinen for all the time he spend helpi
On 12/18/2012 06:04 AM, Dave Airlie wrote:
Many developers showed interest in the first RFC, and I've had the opportunity
to discuss it with most of them. I would like to thank (in no particular
order) Tomi Valkeinen for all the time he spend helping me to draft v2, Marcus
Lorentzon fo
On 04/18/2012 06:06 PM, Ville Syrj?l? wrote:
>> > If you smash everything into one ioctl, I imagine you have plenty of fun
>> > implementing all this. Which is why I prefer to split this up.
> I don't think there's that much differnce. You build up the full device
> state, check it, and when you'
On 04/18/2012 05:43 PM, Luc Verhaegen wrote:
> This means that there should be (at least) three separate actions:
> * page flipping: buffers -> planes at next vblank, for a list of
> buffer(s) and plane tuples.
> * setplanes: colour format, position, scaling, ordering, rotation, color
> key, crtc
On 04/18/2012 05:27 PM, Daniel Vetter wrote:
> On Wed, Apr 18, 2012 at 05:10:47PM +0200, Marcus Lorentzon wrote:
>> On 04/18/2012 04:36 PM, Daniel Vetter wrote:
>>> Last time around I've discussed with people we've ended up with 2 new
>>> ioctls:
>>>
On 04/18/2012 04:36 PM, Daniel Vetter wrote:
> Last time around I've discussed with people we've ended up with 2 new
> ioctls:
>
> - atomic modeset, to configure the output state on more than one crtc at
>the same time. This is useful to get pll assignement, memory bandwidth
>constrains and
On 04/18/2012 04:26 PM, Ville Syrj?l? wrote:
> On Wed, Apr 18, 2012 at 04:04:56PM +0200, Marcus Lorentzon wrote:
>> On 04/18/2012 02:25 PM, Rob Clark wrote:
>>> On Wed, Apr 18, 2012 at 5:11 AM, Joonyoung Shim
>>> wrote:
>>>> On 04/18/2012 05:46 PM, Da
On 04/18/2012 02:25 PM, Rob Clark wrote:
> On Wed, Apr 18, 2012 at 5:11 AM, Joonyoung Shim
> wrote:
>> On 04/18/2012 05:46 PM, Daniel Vetter wrote:
>>> On Wed, Apr 18, 2012 at 01:31:59PM +0900, Joonyoung Shim wrote:
DRM_MODE_PLANE_EVENT is similar to DRM_MODE_PAGE_FLIP_EVENT but it is
f
On 04/18/2012 06:06 PM, Ville Syrjälä wrote:
> If you smash everything into one ioctl, I imagine you have plenty of fun
> implementing all this. Which is why I prefer to split this up.
I don't think there's that much differnce. You build up the full device
state, check it, and when you're read
On 04/18/2012 05:43 PM, Luc Verhaegen wrote:
This means that there should be (at least) three separate actions:
* page flipping: buffers -> planes at next vblank, for a list of
buffer(s) and plane tuples.
* setplanes: colour format, position, scaling, ordering, rotation, color
key, crtc adheranc
On 04/18/2012 05:27 PM, Daniel Vetter wrote:
On Wed, Apr 18, 2012 at 05:10:47PM +0200, Marcus Lorentzon wrote:
On 04/18/2012 04:36 PM, Daniel Vetter wrote:
Last time around I've discussed with people we've ended up with 2 new
ioctls:
- atomic modeset, to configure the output sta
On 04/18/2012 04:36 PM, Daniel Vetter wrote:
Last time around I've discussed with people we've ended up with 2 new
ioctls:
- atomic modeset, to configure the output state on more than one crtc at
the same time. This is useful to get pll assignement, memory bandwidth
constrains and similar
On 04/18/2012 04:26 PM, Ville Syrjälä wrote:
On Wed, Apr 18, 2012 at 04:04:56PM +0200, Marcus Lorentzon wrote:
On 04/18/2012 02:25 PM, Rob Clark wrote:
On Wed, Apr 18, 2012 at 5:11 AM, Joonyoung Shim
wrote:
On 04/18/2012 05:46 PM, Daniel Vetter wrote:
On Wed, Apr 18, 2012 at 01:31:59PM
On 04/18/2012 02:25 PM, Rob Clark wrote:
On Wed, Apr 18, 2012 at 5:11 AM, Joonyoung Shim wrote:
On 04/18/2012 05:46 PM, Daniel Vetter wrote:
On Wed, Apr 18, 2012 at 01:31:59PM +0900, Joonyoung Shim wrote:
DRM_MODE_PLANE_EVENT is similar to DRM_MODE_PAGE_FLIP_EVENT but it is
for a plane. The s
On 03/30/2012 12:12 PM, Ville Syrj?l? wrote:
>> +#define DRM_FORMAT_NV12MT fourcc_code('T', 'M', '1', '2') /* 2x2
>> subsampled Cr:Cb plane 64x32 macroblocks */
> This one is more difficult. Until now tiling was always handled in
> driver specific manner. OTOH if this format is really supported
On 03/30/2012 12:37 PM, Ville Syrj?l? wrote:
> On Thu, Mar 29, 2012 at 08:15:48PM -0500, Rob Clark wrote:
>> On Thu, Mar 29, 2012 at 8:02 PM, Rob Clark wrote:
>>> From: Rob Clark
>>>
>>> A bitmask property is similar to an enum. The enum value is a bit
>>> position (0-63), and valid property valu
On 03/30/2012 12:12 PM, Ville Syrjälä wrote:
+#define DRM_FORMAT_NV12MT fourcc_code('T', 'M', '1', '2') /* 2x2
subsampled Cr:Cb plane 64x32 macroblocks */
This one is more difficult. Until now tiling was always handled in
driver specific manner. OTOH if this format is really supported by
d
On 03/30/2012 12:37 PM, Ville Syrjälä wrote:
On Thu, Mar 29, 2012 at 08:15:48PM -0500, Rob Clark wrote:
On Thu, Mar 29, 2012 at 8:02 PM, Rob Clark wrote:
From: Rob Clark
A bitmask property is similar to an enum. The enum value is a bit
position (0-63), and valid property values consist of a
Hi Paulo,
thanks for a quick response posting the patches.
In my use of CRTC rotation properties, I need the change to be
synchronized with modeset. Your implementation activate the property
change immediately instead of staging it for next modeset. Do you think
it is ok for different drivers t
Hi Paulo,
thanks for a quick response posting the patches.
In my use of CRTC rotation properties, I need the change to be
synchronized with modeset. Your implementation activate the property
change immediately instead of staging it for next modeset. Do you think
it is ok for different drivers
On 03/19/2012 05:56 PM, Alan Cox wrote:
>> display controller will be reading the front buffer, but the GPU
>> > might also need to read that front buffer. So perhaps adding
>> > "read-only"& "read-write" access flags to prepare could also be
>> > interpreted as shared& exclusive accesses, if
On 03/19/2012 05:56 PM, Alan Cox wrote:
display controller will be reading the front buffer, but the GPU
> might also need to read that front buffer. So perhaps adding
> "read-only"& "read-write" access flags to prepare could also be
> interpreted as shared& exclusive accesses, if we went do
On 03/15/2012 02:32 AM, Rob Clark wrote:
> From: Rob Clark
> [snip]
> In all cases, the mmap() call is allowed to fail, and the associated
> dma_buf_ops are optional (mmap() will fail if at least the mmap()
> op is not implemented by the exporter, but in either case the
> {prepare,finish}_access()
On 03/15/2012 02:32 AM, Rob Clark wrote:
From: Rob Clark
[snip]
In all cases, the mmap() call is allowed to fail, and the associated
dma_buf_ops are optional (mmap() will fail if at least the mmap()
op is not implemented by the exporter, but in either case the
{prepare,finish}_access() ops are op
On 2 March 2012 15:23, Heiko St?bner wrote:
> Am Freitag, 17. Februar 2012, 00:25:51 schrieb Laurent Pinchart:
> [...]
> > For DSI, a possible abstraction level would be a DCS (Display Command
> > Set) bus. Panels and/or HDMI-on-DSI transmitter drivers would be
> > implemented as DCS drivers.
>
On 2 March 2012 15:23, Heiko Stübner wrote:
> Am Freitag, 17. Februar 2012, 00:25:51 schrieb Laurent Pinchart:
> [...]
> > For DSI, a possible abstraction level would be a DCS (Display Command
> > Set) bus. Panels and/or HDMI-on-DSI transmitter drivers would be
> > implemented as DCS drivers.
>
On 06/22/2011 03:09 AM, Rob Clark wrote:
> But I'm at least under the impression that some of the other SoC's
> have similar flexibility to use video planes as either primary or
> overlay layers. So I figure it is at least worth trying to handle
> this in a more generic way if it doesn't cause too
On 06/22/2011 03:09 AM, Rob Clark wrote:
But I'm at least under the impression that some of the other SoC's
have similar flexibility to use video planes as either primary or
overlay layers. So I figure it is at least worth trying to handle
this in a more generic way if it doesn't cause too much
On 06/20/2011 10:11 PM, Jesse Barnes wrote:
> This version adds both source and dest rect params to the set_plane
> ioctl, and makes the source fixed point to support hardware that needs
> it.
>
> I haven't changed the name of the SNB implementation yet (per Chris's
> suggestions) but will before i
On 06/20/2011 10:11 PM, Jesse Barnes wrote:
This version adds both source and dest rect params to the set_plane
ioctl, and makes the source fixed point to support hardware that needs
it.
I haven't changed the name of the SNB implementation yet (per Chris's
suggestions) but will before it gets up
On 06/08/2011 08:54 PM, Jesse Barnes wrote:
> On Wed, 8 Jun 2011 11:41:17 +0200
> Marcus Lorentzon wrote:
>
>
>> On 06/07/2011 11:01 PM, Jesse Barnes wrote:
>>
>>> On Tue, 7 Jun 2011 13:07:39 -0700
>>> Jesse Barnes wrote:
>>>
>
On 06/08/2011 08:54 PM, Jesse Barnes wrote:
On Wed, 8 Jun 2011 11:41:17 +0200
Marcus Lorentzon wrote:
On 06/07/2011 11:01 PM, Jesse Barnes wrote:
On Tue, 7 Jun 2011 13:07:39 -0700
Jesse Barnes wrote:
+/* Planes blend with or override other bits on the CRTC */
+struct
On 06/07/2011 11:01 PM, Jesse Barnes wrote:
> On Tue, 7 Jun 2011 13:07:39 -0700
> Jesse Barnes wrote:
>
>
>> +/* Planes blend with or override other bits on the CRTC */
>> +struct drm_mode_set_plane {
>> +__u32 plane_id;
>> +__u32 crtc_id;
>> +__u32 fb_id; /* contains surface form
On 06/07/2011 11:01 PM, Jesse Barnes wrote:
On Tue, 7 Jun 2011 13:07:39 -0700
Jesse Barnes wrote:
+/* Planes blend with or override other bits on the CRTC */
+struct drm_mode_set_plane {
+ __u32 plane_id;
+ __u32 crtc_id;
+ __u32 fb_id; /* contains surface format type */
On 03/12/2011 04:59 PM, Rob Clark wrote:
> On Sun, Dec 5, 2010 at 5:28 AM, Daniel Vetter wrote:
>
>> On Sat, Dec 04, 2010 at 04:34:22PM -0500, Alex Deucher wrote:
>>
>>> This doesn't seem that different from the graphics chips we support
>>> with kms. I don't think it would require much
On 03/12/2011 04:59 PM, Rob Clark wrote:
On Sun, Dec 5, 2010 at 5:28 AM, Daniel Vetter wrote:
On Sat, Dec 04, 2010 at 04:34:22PM -0500, Alex Deucher wrote:
This doesn't seem that different from the graphics chips we support
with kms. I don't think it would require much work to use K
On 12/17/2010 12:22 PM, Arnd Bergmann wrote:
>>> * When I talk about a bus, I mean 'struct bus_type', which identifies
>>> all devices with a uniform bus interface to their parent device
>>> (think: PCI, USB, I2C). You seem to think of a bus as a specific
>>> instance of that bus type,
On 12/17/2010 12:22 PM, Arnd Bergmann wrote:
* When I talk about a bus, I mean 'struct bus_type', which identifies
all devices with a uniform bus interface to their parent device
(think: PCI, USB, I2C). You seem to think of a bus as a specific
instance of that bus type, i.e. the devic
On 11/26/2010 12:24 PM, Arnd Bergmann wrote:
> [dri people: please have a look at the KMS discussion way below]
>
> On Thursday 25 November 2010 19:00:26 Marcus LORENTZON wrote:
>
>>> -Original Message-
>>> From: Arnd Bergmann [mailto:arnd at arndb.de]
>
On 11/26/2010 12:24 PM, Arnd Bergmann wrote:
[dri people: please have a look at the KMS discussion way below]
On Thursday 25 November 2010 19:00:26 Marcus LORENTZON wrote:
-Original Message-
From: Arnd Bergmann [mailto:a...@arndb.de]
Sent: den 25 november 2010 17:48
To: Marcus
66 matches
Mail list logo
