From: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
To: Keith Packard <keithp@keithp.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>,
linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org, linaro-dev@lists.linaro.org,
"Clark, Rob" <rob@ti.com>, Archit Taneja <archit@ti.com>
Subject: Re: Proposal for a low-level Linux display framework
Date: Thu, 15 Sep 2011 17:12:43 +0000 [thread overview]
Message-ID: <4E72320B.6020000@gmx.de> (raw)
In-Reply-To: <yun8vpp7qk7.fsf@aiko.keithp.com>
On 09/15/2011 03:50 PM, Keith Packard wrote:
> On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>
>> 1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
>> the plan is to make DRM the core Linux display framework, upon which
>> everything else is built, and fb and v4l2 are changed to use DRM.
>
> I'd like to think we could make DRM the underlying display framework;
> it already exposes an fb interface, and with overlays, a bit more of the
> v4l2 stuff is done as well. Certainly eliminating three copies of mode
> setting infrastructure would be nice...
Interesting that this comes from the people that pushed the latest mode setting
code into the kernel. But I don't think that this will happen, the exposed user
interfaces will be around for decades and the infrastructure code could be
shared, in theory.
For fb and V4L2 I think we'll develop some level of interoperability, share
concepts and maybe even some code. The FOURCC pixel formats and overlays are
such examples. As Laurent is really interested in it I think we can get some
nice progress here.
For fb and DRM the situation is entirely different. The last proposal I remember
ended in the DRM people stating that only their implementation is acceptable as
is and we could use it. Such attitude is not helpful and as I don't see any
serious intention of the DRM guys to cooperate I think those subsystems are more
likely to diverge. At least I'll never accept any change to the fb
infrastructure that requires DRM.
Regards,
Florian Tobias Schandinat
WARNING: multiple messages have this Message-ID (diff)
From: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
To: Keith Packard <keithp@keithp.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>,
linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org, linaro-dev@lists.linaro.org,
"Clark\, Rob" <rob@ti.com>, Archit Taneja <archit@ti.com>
Subject: Re: Proposal for a low-level Linux display framework
Date: Thu, 15 Sep 2011 17:12:43 +0000 [thread overview]
Message-ID: <4E72320B.6020000@gmx.de> (raw)
In-Reply-To: <yun8vpp7qk7.fsf@aiko.keithp.com>
On 09/15/2011 03:50 PM, Keith Packard wrote:
> On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>
>> 1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
>> the plan is to make DRM the core Linux display framework, upon which
>> everything else is built, and fb and v4l2 are changed to use DRM.
>
> I'd like to think we could make DRM the underlying display framework;
> it already exposes an fb interface, and with overlays, a bit more of the
> v4l2 stuff is done as well. Certainly eliminating three copies of mode
> setting infrastructure would be nice...
Interesting that this comes from the people that pushed the latest mode setting
code into the kernel. But I don't think that this will happen, the exposed user
interfaces will be around for decades and the infrastructure code could be
shared, in theory.
For fb and V4L2 I think we'll develop some level of interoperability, share
concepts and maybe even some code. The FOURCC pixel formats and overlays are
such examples. As Laurent is really interested in it I think we can get some
nice progress here.
For fb and DRM the situation is entirely different. The last proposal I remember
ended in the DRM people stating that only their implementation is acceptable as
is and we could use it. Such attitude is not helpful and as I don't see any
serious intention of the DRM guys to cooperate I think those subsystems are more
likely to diverge. At least I'll never accept any change to the fb
infrastructure that requires DRM.
Regards,
Florian Tobias Schandinat
next prev parent reply other threads:[~2011-09-15 17:12 UTC|newest]
Thread overview: 143+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-15 12:07 Proposal for a low-level Linux display framework Tomi Valkeinen
2011-09-15 12:07 ` Tomi Valkeinen
2011-09-15 12:07 ` Tomi Valkeinen
2011-09-15 14:59 ` Keith Packard
2011-09-15 14:59 ` Keith Packard
2011-09-15 14:59 ` Keith Packard
2011-09-15 15:29 ` Tomi Valkeinen
2011-09-15 15:29 ` Tomi Valkeinen
2011-09-15 15:29 ` Tomi Valkeinen
2011-09-15 15:50 ` Keith Packard
2011-09-15 15:50 ` Keith Packard
2011-09-15 15:50 ` Keith Packard
2011-09-15 17:05 ` Alan Cox
2011-09-15 17:05 ` Alan Cox
2011-09-15 17:05 ` Alan Cox
2011-09-17 21:36 ` Laurent Pinchart
2011-09-17 21:36 ` Laurent Pinchart
2011-09-17 21:36 ` Laurent Pinchart
2011-09-15 17:12 ` Florian Tobias Schandinat [this message]
2011-09-15 17:12 ` Florian Tobias Schandinat
2011-09-15 17:18 ` Alan Cox
2011-09-15 17:18 ` Alan Cox
2011-09-15 17:18 ` Alan Cox
2011-09-15 17:47 ` Florian Tobias Schandinat
2011-09-15 17:47 ` Florian Tobias Schandinat
2011-09-15 19:05 ` Alan Cox
2011-09-15 19:05 ` Alan Cox
2011-09-15 19:05 ` Alan Cox
2011-09-15 19:46 ` Florian Tobias Schandinat
2011-09-15 19:46 ` Florian Tobias Schandinat
2011-09-15 21:31 ` Alan Cox
2011-09-15 21:31 ` Alan Cox
2011-09-15 21:31 ` Alan Cox
2011-09-15 17:52 ` Alex Deucher
2011-09-15 17:52 ` Alex Deucher
2011-09-15 17:56 ` Geert Uytterhoeven
2011-09-15 17:56 ` Geert Uytterhoeven
2011-09-15 18:04 ` Alex Deucher
2011-09-15 18:04 ` Alex Deucher
2011-09-15 18:04 ` Alex Deucher
2011-09-15 18:07 ` Corbin Simpson
2011-09-15 18:07 ` Corbin Simpson
2011-09-15 18:39 ` Florian Tobias Schandinat
2011-09-15 18:58 ` Alan Cox
2011-09-15 18:58 ` Alan Cox
2011-09-15 18:58 ` Alan Cox
2011-09-15 19:18 ` Florian Tobias Schandinat
[not found] ` <4E724F93.1050203-Mmb7MZpHnFY@public.gmane.org>
2011-09-15 19:28 ` Alan Cox
2011-09-15 19:28 ` Alan Cox
2011-09-15 19:28 ` Alan Cox
2011-09-15 19:45 ` Alex Deucher
2011-09-15 19:45 ` Alex Deucher
2011-09-17 14:44 ` Felipe Contreras
2011-09-17 14:44 ` Felipe Contreras
2011-09-17 15:16 ` Rob Clark
2011-09-17 15:16 ` Rob Clark
2011-09-17 15:16 ` Rob Clark
2011-09-17 16:11 ` Florian Tobias Schandinat
2011-09-17 16:11 ` Florian Tobias Schandinat
2011-09-17 16:47 ` Dave Airlie
2011-09-17 16:47 ` Dave Airlie
2011-09-17 16:47 ` Dave Airlie
2011-09-17 18:15 ` Florian Tobias Schandinat
2011-09-17 18:23 ` Dave Airlie
2011-09-17 18:23 ` Dave Airlie
2011-09-17 18:23 ` Dave Airlie
2011-09-17 19:06 ` Florian Tobias Schandinat
2011-09-17 19:25 ` Corbin Simpson
2011-09-17 19:25 ` Corbin Simpson
2011-09-17 21:25 ` Alex Deucher
2011-09-17 21:25 ` Alex Deucher
2011-09-17 21:25 ` Alex Deucher
2011-09-17 20:25 ` Alan Cox
2011-09-17 20:25 ` Alan Cox
2011-09-17 20:25 ` Alan Cox
2011-10-31 20:24 ` Jesse Barnes
2011-10-31 20:24 ` Jesse Barnes
2011-09-17 16:50 ` Rob Clark
2011-09-17 16:50 ` Rob Clark
2011-09-16 4:53 ` Keith Packard
2011-09-16 4:53 ` Keith Packard
2011-09-16 4:53 ` Keith Packard
2011-09-17 23:12 ` Laurent Pinchart
2011-09-17 23:12 ` Laurent Pinchart
2011-09-17 23:12 ` Laurent Pinchart
2011-09-18 16:14 ` Rob Clark
2011-09-18 16:14 ` Rob Clark
2011-09-18 16:14 ` Rob Clark
2011-09-18 21:55 ` Laurent Pinchart
2011-09-18 21:55 ` Laurent Pinchart
2011-09-18 21:55 ` Laurent Pinchart
[not found] ` <201109180112.15896.laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
2011-09-18 22:23 ` Alan Cox
2011-09-18 22:23 ` Alan Cox
2011-09-18 22:23 ` Alan Cox
2011-09-19 0:09 ` Rob Clark
2011-09-19 0:09 ` Rob Clark
2011-09-20 23:32 ` Laurent Pinchart
2011-09-20 23:32 ` Laurent Pinchart
2011-09-15 18:12 ` Keith Packard
2011-09-15 18:12 ` Keith Packard
2011-09-15 18:12 ` Keith Packard
2011-10-01 17:30 ` Enrico Weigelt
2011-09-15 17:21 ` Tomi Valkeinen
2011-09-15 17:21 ` Tomi Valkeinen
2011-09-15 18:32 ` Rob Clark
2011-09-15 18:32 ` Rob Clark
2011-09-15 18:32 ` Rob Clark
2011-09-16 0:55 ` Keith Packard
2011-09-16 0:55 ` Keith Packard
2011-09-16 0:55 ` Keith Packard
2011-09-16 6:38 ` Tomi Valkeinen
2011-09-16 6:38 ` Tomi Valkeinen
2011-09-16 14:17 ` Daniel Vetter
2011-09-16 14:17 ` Daniel Vetter
2011-09-16 16:53 ` Alan Cox
2011-09-16 16:53 ` Alan Cox
2011-09-16 16:53 ` Alan Cox
2011-09-19 6:33 ` Tomi Valkeinen
2011-09-19 6:33 ` Tomi Valkeinen
2011-09-19 6:53 ` Keith Packard
2011-09-19 6:53 ` Keith Packard
2011-09-19 6:53 ` Keith Packard
2011-09-19 7:29 ` Tomi Valkeinen
2011-09-19 7:29 ` Tomi Valkeinen
2011-09-20 8:29 ` Patrik Jakobsson
2011-09-20 8:29 ` Patrik Jakobsson
2011-09-20 8:29 ` Patrik Jakobsson
2011-09-20 15:55 ` Keith Packard
2011-09-20 15:55 ` Keith Packard
2011-09-20 15:55 ` Keith Packard
2011-09-20 21:20 ` Patrik Jakobsson
2011-09-20 21:20 ` Patrik Jakobsson
2011-09-21 6:01 ` Tomi Valkeinen
2011-09-21 6:01 ` Tomi Valkeinen
2011-09-21 18:07 ` Patrik Jakobsson
2011-09-21 18:07 ` Patrik Jakobsson
2011-09-21 18:07 ` Patrik Jakobsson
2011-10-01 17:34 ` Enrico Weigelt
2011-09-15 15:03 ` Kyungmin Park
2011-09-15 15:03 ` Kyungmin Park
2011-09-21 13:26 ` Heiko Stübner
2011-09-21 13:26 ` Heiko Stübner
2011-10-01 16:52 ` Enrico Weigelt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E72320B.6020000@gmx.de \
--to=florianschandinat@gmx.de \
--cc=archit@ti.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=keithp@keithp.com \
--cc=linaro-dev@lists.linaro.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rob@ti.com \
--cc=tomi.valkeinen@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.