* Re: [PATCH 0/2] video: s3c-fb: Add window positioning support
From: Laurent Pinchart @ 2011-09-18 20:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E7646B5.6000000@gmx.de>
Hi Florian,
On Sunday 18 September 2011 21:29:57 Florian Tobias Schandinat wrote:
> On 09/07/2011 03:31 PM, Laurent Pinchart wrote:
> > On Thursday 01 September 2011 18:45:18 Florian Tobias Schandinat wrote:
> >> On 08/25/2011 07:51 PM, Ajay Kumar wrote:
> >>> Just as a note, there are many drivers like mx3fb.c, au1200fb.c and
> >>> OMAP seem to be doing window/plane positioning in their driver code.
> >>> Is it possible to have this window positioning support at a common
> >>> place?
> >>
> >> Good point. Congratulations for figuring out that I like to standardize
> >> things. But I think your suggestion is far from being enough to be
> >> useful for userspace (which is our goal so that applications can be
> >> reused along drivers and don't need to know about individual drivers).
> >
> > Beside standardizing things, do you also like to take them one level
> > higher to solve challenging issues ? I know the answer must be yes :-)
> >
> > The problem at hand here is something we have solved in V4L2
> > (theoretically only for part of it) with the media controller API, the
> > V4L2 subdevs and their pad-level format API.
> >
> > In a nutshell, the media controller lets drivers model hardware as a
> > graph of buliding blocks connected through their pads and expose that
> > description to userspace applications. In V4L2 most of those blocks are
> > V4L2 subdevs, which are abstract building blocks that implement sets of
> > standard operations. Those operations are exposed to userspace through
> > the V4L2 subdevs pad-level format API, allowing application to configure
> > sizes and selection rectangles at all pads in the graph. Selection
> > rectangles can be used to configure cropping and composing, which is
> > exactly what the window positioning API needs to do.
> >
> > Instead of creating a new fbdev-specific API to do the same, shouldn't we
> > try to join forces ?
>
> Okay, thanks for the pointer. After having a look at your API I understand
> that it would solve the problem to discover how many windows (in this
> case) are there and how they can be accessed. It looks fine for this
> purpose, powerful enough and not too complex. So if I get it correct we
> still need at least a way to configure the position of the
> windows/overlays/sink pads similar to what Ajay proposed.
Yes, the media controller API can only expose the topology to userspace, it
can't be used to configure FB-specific parameters on the pipeline.
> Additionally a way to get and/or set the z-position of the overlays if
> multiple overlays overlap and set/get how the overlays work (overdraw,
> constant alpha, source/destination color keying). Normally I'd consider
> these link properties but I think implementing them as properties of the
> source framebuffer or sink pad would work as well.
> Is this correct or did I miss something?
That's correct.
What bothers me is that both V4L2 and DRM/KMS have the exact same needs. I
don't think it makes sense to implement three different solutions to the same
problem in our three video-related APIs. What's your opinion about that ?
I've tried to raise the issue on the dri-devel mailing list ("Proposal for a
low-level Linux display framework"), but there's still a long way to go before
convincing everybody. Feel free to help me :-)
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 0/13] drivers/video: fsl-diu-fb: several minor improvements
From: Florian Tobias Schandinat @ 2011-09-18 20:15 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1316123098-30967-1-git-send-email-timur@freescale.com>
On 09/15/2011 09:44 PM, Timur Tabi wrote:
> This patchset includes several minor improvements to the Freescale DIU
> framebuffer driver.
Applied. Thanks for splitting it up.
Best regards,
Florian Tobias Schandinat
^ permalink raw reply
* Re: [PATCH v3 0/3] fbdev: Add FOURCC-based format configuration API
From: Florian Tobias Schandinat @ 2011-09-18 19:49 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linux-fbdev, linux-media, magnus.damm
In-Reply-To: <1314789501-824-1-git-send-email-laurent.pinchart@ideasonboard.com>
Hi all,
as there was no reaction to this patch series I am scheduling it for 3.3 merge
window (3.2 seems too close to me as this is an API change). As the second patch
has nothing to do with fbdev it should go mainline via V4L2. Any problems/comments?
Best regards,
Florian Tobias Schandinat
On 08/31/2011 11:18 AM, Laurent Pinchart wrote:
> Hi everybody,
>
> Here's the third version of the fbdev FOURCC-based format configuration API.
>
> Compared to the previous version, I've added an FB_TYPE_FOURCC in addition to
> FB_VISUAL_FOURCC, fixed the documentation (thanks to Geert for reviewing it
> and explaining how fbdev bitplanes work) and fixed bugs in the sh_mobile_lcdc
> YUV support.
>
> The sb_mobile_lcdc patch applies on top of the latest patches that I've sent
> to the list. You can find a consolidated version that includes this patch set
> at http://git.linuxtv.org/pinchartl/fbdev.git/shortlog/refs/heads/fbdev-yuv.
>
> I've updated the fbdev-test tool to add FOURCC support. The code is available
> in the fbdev-test yuv branch at
> http://git.ideasonboard.org/?pûdev-test.git;a=shortlog;h=refs/heads/yuv.
>
> Laurent Pinchart (3):
> fbdev: Add FOURCC-based format configuration API
> v4l: Add V4L2_PIX_FMT_NV24 and V4L2_PIX_FMT_NV42 formats
> fbdev: sh_mobile_lcdc: Support FOURCC-based format API
>
> Documentation/DocBook/media/v4l/pixfmt-nv24.xml | 129 ++++++++
> Documentation/DocBook/media/v4l/pixfmt.xml | 1 +
> Documentation/fb/api.txt | 317 ++++++++++++++++++++
> arch/arm/mach-shmobile/board-ag5evm.c | 2 +-
> arch/arm/mach-shmobile/board-ap4evb.c | 4 +-
> arch/arm/mach-shmobile/board-mackerel.c | 4 +-
> arch/sh/boards/mach-ap325rxa/setup.c | 2 +-
> arch/sh/boards/mach-ecovec24/setup.c | 2 +-
> arch/sh/boards/mach-kfr2r09/setup.c | 2 +-
> arch/sh/boards/mach-migor/setup.c | 4 +-
> arch/sh/boards/mach-se/7724/setup.c | 2 +-
> drivers/video/sh_mobile_lcdcfb.c | 362 +++++++++++++++--------
> include/linux/fb.h | 28 ++-
> include/linux/videodev2.h | 2 +
> include/video/sh_mobile_lcdc.h | 4 +-
> 15 files changed, 726 insertions(+), 139 deletions(-)
> create mode 100644 Documentation/DocBook/media/v4l/pixfmt-nv24.xml
> create mode 100644 Documentation/fb/api.txt
>
^ permalink raw reply
* Re: [PATCH 0/2] video: s3c-fb: Add window positioning support
From: Florian Tobias Schandinat @ 2011-09-18 19:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201109071731.02293.laurent.pinchart@ideasonboard.com>
Hi Laurent,
On 09/07/2011 03:31 PM, Laurent Pinchart wrote:
> Hi Florian,
>
> On Thursday 01 September 2011 18:45:18 Florian Tobias Schandinat wrote:
>> Hi all,
>>
>> On 08/25/2011 07:51 PM, Ajay Kumar wrote:
>>> Just as a note, there are many drivers like mx3fb.c, au1200fb.c and OMAP
>>> seem to be doing window/plane positioning in their driver code.
>>> Is it possible to have this window positioning support at a common place?
>>
>> Good point. Congratulations for figuring out that I like to standardize
>> things. But I think your suggestion is far from being enough to be useful
>> for userspace (which is our goal so that applications can be reused along
>> drivers and don't need to know about individual drivers).
>
> Beside standardizing things, do you also like to take them one level higher to
> solve challenging issues ? I know the answer must be yes :-)
>
> The problem at hand here is something we have solved in V4L2 (theoretically
> only for part of it) with the media controller API, the V4L2 subdevs and their
> pad-level format API.
>
> In a nutshell, the media controller lets drivers model hardware as a graph of
> buliding blocks connected through their pads and expose that description to
> userspace applications. In V4L2 most of those blocks are V4L2 subdevs, which
> are abstract building blocks that implement sets of standard operations. Those
> operations are exposed to userspace through the V4L2 subdevs pad-level format
> API, allowing application to configure sizes and selection rectangles at all
> pads in the graph. Selection rectangles can be used to configure cropping and
> composing, which is exactly what the window positioning API needs to do.
>
> Instead of creating a new fbdev-specific API to do the same, shouldn't we try
> to join forces ?
Okay, thanks for the pointer. After having a look at your API I understand that
it would solve the problem to discover how many windows (in this case) are there
and how they can be accessed. It looks fine for this purpose, powerful enough
and not too complex. So if I get it correct we still need at least a way to
configure the position of the windows/overlays/sink pads similar to what Ajay
proposed. Additionally a way to get and/or set the z-position of the overlays if
multiple overlays overlap and set/get how the overlays work (overdraw, constant
alpha, source/destination color keying). Normally I'd consider these link
properties but I think implementing them as properties of the source framebuffer
or sink pad would work as well.
Is this correct or did I miss something?
Best regards,
Florian Tobias Schandinat
^ permalink raw reply
* Re: Proposal for a low-level Linux display framework
From: Rob Clark @ 2011-09-18 16:14 UTC (permalink / raw)
To: Laurent Pinchart
Cc: linux-fbdev, linaro-dev, Florian Tobias Schandinat, linux-kernel,
dri-devel, Archit Taneja
In-Reply-To: <201109180112.15896.laurent.pinchart@ideasonboard.com>
On Sat, Sep 17, 2011 at 6:12 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> Hi everybody,
>
> On Thursday 15 September 2011 20:39:21 Florian Tobias Schandinat wrote:
>> On 09/15/2011 05:52 PM, Alex Deucher wrote:
>> >
>> > Please don't claim that the DRM developers do not want to cooperate.
>> > I realize that people have strong opinions about existing APIs, put
>> > there has been just as much, if not more obstinacy from the v4l and fb
>> > people.
>>
>> Well, I think it's too late to really fix this thing. We now have 3 APIs in
>> the kernel that have to be kept. Probably the best we can do now is figure
>> out how we can reduce code duplication and do extensions to those APIs in
>> a way that they are compatible with each other or completely independent
>> and can be used across the APIs.
>
> Sorry for jumping late into the discussion. Let me try to shed some new light
> on this.
>
> I've been thinking about the DRM/KMS/FB/V4L APIs overlap for quite some time
> now. All of them have their share of issues, historical nonsense and unique
> features. I don't think we can pick one of those APIs today and decide to drop
> the others, but we certainly need to make DRM, KMS, FB and V4L interoperable
> at various levels. The alternative is to keep ignoring each other and let the
> market decice.
I think we need to differentiate between V4L camera, and display..
MC and subdev stuff clearly seem to be the way to go for complex
camera / imaging subsystems. But that is a very different problem
domain from GPU+display. We need to stop blurring the two topics.
> Thinking that the market could pick something like OpenMAX
> scares me, so I'd rather find a good compromise and move forward.
>
> Disclaimer: My DRM/KMS knowledge isn't as good as my FB and V4L knowledge, so
> please feel free to correct my mistakes.
>
> All our video-related APIs started as solutions to different problems. They
> all share an important feature: they assume that the devices they control is
> more or less monolithic. For that reason they expose a single device to
> userspace, and mix device configuration and data transfer on the same device
> node.
>
> This shortcoming became painful in V4L a couple of years ago. When I started
> working on the OMAP3 ISP (camera) driver I realized that trying to configure a
> complex hardware pipeline without exposing its internals to userspace
> applications wouldn't be possible. DRM, KMS and FB ran into the exact same
> problem, just more recently, as showed by various RFCs ([1], [2]).
But I do think that overlays need to be part of the DRM/KMS interface,
simply because flipping still needs to be synchronized w/ the GPU. I
have some experience using V4L for display, and this is one (of
several) broken aspects of that.
> To fix this issue, the V4L community developed a new API called the Media
> Controller [3]. In a nutshell, the MC aims at
>
> - exposing the device topology to userspace as an oriented graph of entities
> connected with links through pads
>
> - controlling the device topology from userspace by enabling/disabling links
>
> - giving userspace access to per-entity controls
>
> - configuring formats at individual points in the pipeline from userspace.
>
> The MC API solves the first two problems. The last two require help from V4L
> (which has been extended with new MC-aware ioctls), as MC is media-agnostic
> and can't thus configure video formats.
>
> To support this, the V4L subsystem exposes an in-kernel API based around the
> concept of sub-devices. A single high-level hardware device is handled by
> multiple sub-devices, possibly controlled by different drivers. For instance,
> in the OMAP3-based N900 digital camera, the OMAP3 ISP is made of 8 sub-devices
> (all controlled by the OMAP3 ISP driver), and the two sensors, flash
> controller and lens controller all have their own sub-device, each of them
> controlled by its own driver.
>
> All this infrastructure exposes the devices a the graph showed in [4] to
> applications, and the V4L sub-device API can be used to set formats at
> individual pads. This allows controlling scaling, cropping, composing and
> other video-related operations on the pipeline.
>
> With the introduction of the media controller architecture, I now see V4L as
> being made of three parts.
>
> 1. The V4L video nodes streaming API, used to manage video buffers memory, map
> it to userspace, and control video streaming (and data transfers).
>
> 2. The V4L sub-devices API, used to control parameters on individual entities
> in the graph and configure formats.
>
> 3. The V4L video nodes formats and control API, used to perform the same tasks
> as the V4L sub-devices API for drivers that don't support the media controller
> API, or to provide support for pure V4L applications with drivers that support
> the media controller API.
>
> V4L is made of those three parts, but I believe it helps to think about them
> individually. With today's (and tomorrow's) devices, DRM, KMS and FB are in a
> situation similar to what V4L experienced a couple of years ago. They need to
> give control of complex pipelines to userspace, and I believe this should be
> done by (logically) splitting DRM, KMS and FB into a pipeline control part and
> a data flow part, as we did with V4L.
>
> Keeping the monolithic device model and handling pipeline control without
> exposing the pipeline topology would in my opinion be a mistake. Even if this
> could support today's hardware, I don't think it would be future-proof. I
> would rather see the DRM, KMS and FB topologies being exposed to applications
> by implementing the MC API in DRM, KMS and FB drivers. I'm working on a proof
> of concept for the FB sh_mobile_lcdc driver and will post patches soon.
> Something similar can be done for DRM and KMS.
>
> This would leave us with the issue of controlling formats and other parameters
> on the pipelines. We could keep separate DRM, KMS, FB and V4L APIs for that,
> but would it really make sense ? I don't think so. Obviously I would be happy
> to use the V4L API, as we already have a working solution :-) I don't see that
> as being realistic though, we will probably need to create a central graphics-
> related API here (possibly close to what we already have in V4L if it can
> fulfil everybody's needs).
>
> To paraphrase Alan, in my semi-perfect world vision the MC API would be used
> to expose hardware pipelines to userspace, a common graphics API would be used
> to control parameters on the pipeline shared by DRM, KMS, FB and V4L, the
> individual APIs would control subsystem-specific parameters and DRM, KMS, FB
> and V4L would be implemented on top of this to manage memory, command queues
> and data transfers.
I guess in theory it would be possible to let MC iterate the
plane->crtc->encoder->connector topology.. I'm not entirely sure what
benefit that would bring, other than change for the sake of change.
V4L and DRM are very different APIs designed to solves very different
problems. The KMS / mode-setting part may look somewhat similar to
something you can express w/ a camera-like graph of nodes. But the
memory management is very different. And display updates (like page
flipping) need to be synchronized w/ GPU rendering.. etc. Trying to
fit V4L here, just seems like trying to force a square peg in a round
hole. You'd have to end up morphing V4L so much that in the end it
looks like DRM. And that might not be the right thing for cameras.
So V4L for camera, DRM for gpu/display. Those are the two APIs we need.
BR,
-R
> Am I looking too far in the future ?
>
> [1] http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg04421.html
> [2] http://www.mail-archive.com/linux-samsung-
> soc@vger.kernel.org/msg06292.html
> [3] http://linuxtv.org/downloads/v4l-dvb-apis/media_common.html
> [4] http://www.ideasonboard.org/media/omap3isp.ps
>
> --
> Regards,
>
> Laurent Pinchart
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
^ permalink raw reply
* [PATCH] zorro: Defer device_register() until all devices have been
From: Geert Uytterhoeven @ 2011-09-18 9:37 UTC (permalink / raw)
To: Linux/m68k; +Cc: Linux Kernel Development, Ingo Jürgensmann, linux-fbdev
As the Amiga Zorro II address space is limited to 8.5 MiB and Zorro devices
can contain only one BAR, several Amiga Zorro II expansion boards (mainly
graphics cards) contain multiple Zorro devices: a small one for the control
registers and one (or more) for the graphics memory.
The conversion of cirrusfb to the new driver framework introduced a
regression: the driver contains a zorro_driver for the first Zorro device,
and uses the (old) zorro_find_device() call to find the second Zorro
device.
However, as the Zorro core calls device_register() as soon as a Zorro
device is identified, it may not have identified the second Zorro device
belonging to the same physical Zorro expansion card. Hence cirrusfb could
no longer find the second part of the Picasso II graphics card, causing a
NULL pointer dereference.
Defer the registration of Zorro devices with the driver framework until
all Zorro devices have been identified to fix this.
Note that the alternative solution (modifying cirrusfb to register a
zorro_driver for all Zorro devices belonging to a graphics card, instead
of only for the first one, and adding a synchronization mechanism to defer
initialization until all have been found), is not an option, as on some
cards one device may be optional (e.g. the second bank of 2 MiB of
graphics memory on the Picasso IV in Zorro II mode).
Reported-by: Ingo Jürgensmann <ij@2011.bluespice.org>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: stable@kernel.org
---
drivers/zorro/zorro.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/zorro/zorro.c b/drivers/zorro/zorro.c
index c81f88a..6a52b83 100644
--- a/drivers/zorro/zorro.c
+++ b/drivers/zorro/zorro.c
@@ -149,10 +149,10 @@ static int __init amiga_zorro_probe(struct platform_device *pdev)
}
platform_set_drvdata(pdev, bus);
- /* Register all devices */
pr_info("Zorro: Probing AutoConfig expansion devices: %u device%s\n",
zorro_num_autocon, zorro_num_autocon = 1 ? "" : "s");
+ /* First identify all devices ... */
for (i = 0; i < zorro_num_autocon; i++) {
z = &zorro_autocon[i];
z->id = (z->rom.er_Manufacturer<<16) | (z->rom.er_Product<<8);
@@ -173,6 +173,11 @@ static int __init amiga_zorro_probe(struct platform_device *pdev)
dev_set_name(&z->dev, "%02x", i);
z->dev.parent = &bus->dev;
z->dev.bus = &zorro_bus_type;
+ }
+
+ /* ... then register them */
+ for (i = 0; i < zorro_num_autocon; i++) {
+ z = &zorro_autocon[i];
error = device_register(&z->dev);
if (error) {
dev_err(&bus->dev, "Error registering device %s\n",
--
1.7.0.4
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply related
* Re: Proposal for a low-level Linux display framework
From: Laurent Pinchart @ 2011-09-17 23:12 UTC (permalink / raw)
To: Florian Tobias Schandinat
Cc: linaro-dev, linux-fbdev, dri-devel, linux-kernel, Archit Taneja,
Clark, Rob
In-Reply-To: <4E724659.5080709@gmx.de>
Hi everybody,
On Thursday 15 September 2011 20:39:21 Florian Tobias Schandinat wrote:
> On 09/15/2011 05:52 PM, Alex Deucher wrote:
> >
> > Please don't claim that the DRM developers do not want to cooperate.
> > I realize that people have strong opinions about existing APIs, put
> > there has been just as much, if not more obstinacy from the v4l and fb
> > people.
>
> Well, I think it's too late to really fix this thing. We now have 3 APIs in
> the kernel that have to be kept. Probably the best we can do now is figure
> out how we can reduce code duplication and do extensions to those APIs in
> a way that they are compatible with each other or completely independent
> and can be used across the APIs.
Sorry for jumping late into the discussion. Let me try to shed some new light
on this.
I've been thinking about the DRM/KMS/FB/V4L APIs overlap for quite some time
now. All of them have their share of issues, historical nonsense and unique
features. I don't think we can pick one of those APIs today and decide to drop
the others, but we certainly need to make DRM, KMS, FB and V4L interoperable
at various levels. The alternative is to keep ignoring each other and let the
market decice. Thinking that the market could pick something like OpenMAX
scares me, so I'd rather find a good compromise and move forward.
Disclaimer: My DRM/KMS knowledge isn't as good as my FB and V4L knowledge, so
please feel free to correct my mistakes.
All our video-related APIs started as solutions to different problems. They
all share an important feature: they assume that the devices they control is
more or less monolithic. For that reason they expose a single device to
userspace, and mix device configuration and data transfer on the same device
node.
This shortcoming became painful in V4L a couple of years ago. When I started
working on the OMAP3 ISP (camera) driver I realized that trying to configure a
complex hardware pipeline without exposing its internals to userspace
applications wouldn't be possible. DRM, KMS and FB ran into the exact same
problem, just more recently, as showed by various RFCs ([1], [2]).
To fix this issue, the V4L community developed a new API called the Media
Controller [3]. In a nutshell, the MC aims at
- exposing the device topology to userspace as an oriented graph of entities
connected with links through pads
- controlling the device topology from userspace by enabling/disabling links
- giving userspace access to per-entity controls
- configuring formats at individual points in the pipeline from userspace.
The MC API solves the first two problems. The last two require help from V4L
(which has been extended with new MC-aware ioctls), as MC is media-agnostic
and can't thus configure video formats.
To support this, the V4L subsystem exposes an in-kernel API based around the
concept of sub-devices. A single high-level hardware device is handled by
multiple sub-devices, possibly controlled by different drivers. For instance,
in the OMAP3-based N900 digital camera, the OMAP3 ISP is made of 8 sub-devices
(all controlled by the OMAP3 ISP driver), and the two sensors, flash
controller and lens controller all have their own sub-device, each of them
controlled by its own driver.
All this infrastructure exposes the devices a the graph showed in [4] to
applications, and the V4L sub-device API can be used to set formats at
individual pads. This allows controlling scaling, cropping, composing and
other video-related operations on the pipeline.
With the introduction of the media controller architecture, I now see V4L as
being made of three parts.
1. The V4L video nodes streaming API, used to manage video buffers memory, map
it to userspace, and control video streaming (and data transfers).
2. The V4L sub-devices API, used to control parameters on individual entities
in the graph and configure formats.
3. The V4L video nodes formats and control API, used to perform the same tasks
as the V4L sub-devices API for drivers that don't support the media controller
API, or to provide support for pure V4L applications with drivers that support
the media controller API.
V4L is made of those three parts, but I believe it helps to think about them
individually. With today's (and tomorrow's) devices, DRM, KMS and FB are in a
situation similar to what V4L experienced a couple of years ago. They need to
give control of complex pipelines to userspace, and I believe this should be
done by (logically) splitting DRM, KMS and FB into a pipeline control part and
a data flow part, as we did with V4L.
Keeping the monolithic device model and handling pipeline control without
exposing the pipeline topology would in my opinion be a mistake. Even if this
could support today's hardware, I don't think it would be future-proof. I
would rather see the DRM, KMS and FB topologies being exposed to applications
by implementing the MC API in DRM, KMS and FB drivers. I'm working on a proof
of concept for the FB sh_mobile_lcdc driver and will post patches soon.
Something similar can be done for DRM and KMS.
This would leave us with the issue of controlling formats and other parameters
on the pipelines. We could keep separate DRM, KMS, FB and V4L APIs for that,
but would it really make sense ? I don't think so. Obviously I would be happy
to use the V4L API, as we already have a working solution :-) I don't see that
as being realistic though, we will probably need to create a central graphics-
related API here (possibly close to what we already have in V4L if it can
fulfil everybody's needs).
To paraphrase Alan, in my semi-perfect world vision the MC API would be used
to expose hardware pipelines to userspace, a common graphics API would be used
to control parameters on the pipeline shared by DRM, KMS, FB and V4L, the
individual APIs would control subsystem-specific parameters and DRM, KMS, FB
and V4L would be implemented on top of this to manage memory, command queues
and data transfers.
Am I looking too far in the future ?
[1] http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg04421.html
[2] http://www.mail-archive.com/linux-samsung-
soc@vger.kernel.org/msg06292.html
[3] http://linuxtv.org/downloads/v4l-dvb-apis/media_common.html
[4] http://www.ideasonboard.org/media/omap3isp.ps
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: Proposal for a low-level Linux display framework
From: Laurent Pinchart @ 2011-09-17 21:36 UTC (permalink / raw)
To: Alan Cox
Cc: Keith Packard, Tomi Valkeinen, linux-fbdev, linux-kernel,
dri-devel, linaro-dev, Clark, Rob, Archit Taneja
In-Reply-To: <20110915180500.53c70206@lxorguk.ukuu.org.uk>
On Thursday 15 September 2011 19:05:00 Alan Cox wrote:
> On Thu, 15 Sep 2011 10:50:32 -0500
> Keith Packard wrote:
> > On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen 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...
>
> V4L2 needs to interface with the DRM anyway. Lots of current hardware
> wants things like shared 1080i/p camera buffers with video in order to do
> preview on video and the like.
Buffers sharing is a hot topic that has been discussed during Linaro Connect
in August 2011. Even though the discussions were aimed at solving ARM-related
embedded issues, the solution we're working on is not limited to the ARM
platform and will allow applications to pass buffers around between device
drivers from different subsystems.
> In my semi-perfect world vision fb would be a legacy layer on top of DRM.
> DRM would get the silly recovery fail cases fixed, and a kernel console
> would be attachable to a GEM object of your choice.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: Proposal for a low-level Linux display framework
From: Alex Deucher @ 2011-09-17 21:25 UTC (permalink / raw)
To: Florian Tobias Schandinat
Cc: linux-fbdev, linaro-dev, linux-kernel, dri-devel, Archit Taneja,
Rob Clark
In-Reply-To: <4E74EF98.3060106@gmx.de>
On Sat, Sep 17, 2011 at 3:06 PM, Florian Tobias Schandinat
<FlorianSchandinat@gmx.de> wrote:
> On 09/17/2011 06:23 PM, Dave Airlie wrote:
>>>
>>> Is it? Well, okay, I don't want to use any acceleration that can crash my
>>> machine, where can I select it, preferably as compile time option? I didn't find
>>> such a thing for Intel or Radeon. Don't say, I should rely on userspace here or
>>> use fbdev for this.
>>
>> Just tell the X driver to not use acceleration, and it you won't get
>> any acceleration used, then you get complete stability. If a driver
>> writer wants to turn off all accel in the kernel driver, it can, its
>> not an option we've bothered with for intel or radeon since it really
>> makes no sense. To put it simply you don't really seem to understand
>> the driver model around KMS. If no userspace app uses acceleration
>> then no acceleration features will magically happen. If you want to
>> write a simple app against the KMS API like plymouth you can now use
>> the dumb ioctls to create and map a buffer that can be made into a
>> framebuffer. Also you get hw cursors + modesetting.
>
> Again, you seem to not understand my reasoning. The "if" is the problem, it's
> the kernels job to ensure stability. Allowing the userspace to decide whether it
> crashes my machine is not acceptable to me.
> I do not claim that it is impossible to write a KMS driver in a way that it does
> not crash, but it seems more difficult than writing an fbdev driver.
>
It's perfectly valid to write a KMS DRM driver that doesn't support
acceleration in which case it will be just as "stable" as a fbdev
driver. In fact on modern hardware it's probably easier to write a
KMS DRM driver than a fbdev driver because the API and internal
abstractions match the hardware better. If you have hardware with 4
display controllers, 2 DACs, a TMDS encoder, and a DP encoder how do
you decide which combination of components and modes to light up at
boot using fbdev?
Alternatively, if you wanted to support acceleration as well, you can
add a module option to force acceleration off at the kernel level
rather than from userspace. It's trivial.
Alex
^ permalink raw reply
* Re: Proposal for a low-level Linux display framework
From: Alan Cox @ 2011-09-17 20:25 UTC (permalink / raw)
To: Dave Airlie
Cc: linux-fbdev, linaro-dev, Florian Tobias Schandinat, linux-kernel,
dri-devel, Archit Taneja, Rob Clark
In-Reply-To: <CAPM=9txHu7mzH8p8g=FmHsjvmAT-aMy-xEFj4odXEvnbs-bhMw@mail.gmail.com>
> Just tell the X driver to not use acceleration, and it you won't get
> any acceleration used, then you get complete stability. If a driver
> writer wants to turn off all accel in the kernel driver, it can, its
In fact one thing we actually need really is a "dumb" KMS X server to
replace the fbdev X server that unaccel stuff depends upon and which
can't do proper mode handling, multi-head or resizing as a result. A dumb
fb generic request for a back to front copy might also be useful for
shadowfb, or at least indicators so you know what the cache behaviour is
so the X server can pick the right policy.
> We've fixed this in KMS, we don't pass direct mappings to userspace
> that we can't tear down and refault. We only provide objects via
> handles. The only place its a problem is where we expose fbdev legacy
> emulation, since we have to fix the pages.
Which is doable. Horrible but doable. The usb framebuffer code has to
play games like this with the virtual framebuffer in order to track
changes by faulting.
There are still some architectural screwups however. DRM continues the
fbdev worldview that outputs, memory and accelerators are tied together
in lumps we call video cards. That isn't really true for all cases and
with capture/overlay it gets even less true.
Alan
^ permalink raw reply
* Re: Proposal for a low-level Linux display framework
From: Corbin Simpson @ 2011-09-17 19:25 UTC (permalink / raw)
To: Florian Tobias Schandinat
Cc: Dave Airlie, linux-fbdev, linaro-dev, linux-kernel, dri-devel,
Archit Taneja, Rob Clark
In-Reply-To: <4E74EF98.3060106@gmx.de>
On Sat, Sep 17, 2011 at 12:06 PM, Florian Tobias Schandinat
<FlorianSchandinat@gmx.de> wrote:
> Again, you seem to not understand my reasoning. The "if" is the problem, it's
> the kernels job to ensure stability. Allowing the userspace to decide whether it
> crashes my machine is not acceptable to me.
> I do not claim that it is impossible to write a KMS driver in a way that it does
> not crash, but it seems more difficult than writing an fbdev driver.
It is a non-trivial problem, which I would argue is impossible, to
permit acceleration without also permitting the possibility of a GPU
lockup. It is completely legal, in every graphics API, to submit
requests which take multiple seconds to render but are totally valid.
Differentiating between long-running rendering and GPU lockup is
difficult. In addition, determining whether or not a permutation of
register writes will lock up a GPU is a pretty hard problem,
computationally, not to mention the walls of code that would be
required to make this happen. At that point, you might as well run
unaccelerated.
>> The core drm/kms ioctls don't expose acceleration to userspace either,
>> again misinformation seems to drive most of your logic. You can't do
>> generic useful acceleration from the kernel. A lot of modern GPU
>> hardware doesn't even have bitblt engines.
>
> I did not say that it is used directly for acceleration, but wasn't the point of
> DRM to allow acceleration in the first place?
In the Voodoo era, sure. DRM really means that userspace can talk
directly to a card, in a card-specific way; beyond the basic DRM
ioctls for gathering card info, nearly every ioctl is device-specific.
You can't command an nV card with Radeon ioctls. It just so happens,
fortunately, that the only things which differ from card to card and
cannot be abstracted from kernel to userspace are accelerated
rendering commands.
You're conflating DRM and KMS. It's possible to provide KMS without
DRM: Modesetting without acceleration.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
<MostAwesomeDude@gmail.com>
^ permalink raw reply
* Re: Proposal for a low-level Linux display framework
From: Florian Tobias Schandinat @ 2011-09-17 19:06 UTC (permalink / raw)
To: Dave Airlie
Cc: Rob Clark, Felipe Contreras, Alan Cox, linaro-dev, linux-kernel,
dri-devel, Archit Taneja, linux-fbdev
In-Reply-To: <CAPM=9txHu7mzH8p8g=FmHsjvmAT-aMy-xEFj4odXEvnbs-bhMw@mail.gmail.com>
On 09/17/2011 06:23 PM, Dave Airlie wrote:
>>
>> Is it? Well, okay, I don't want to use any acceleration that can crash my
>> machine, where can I select it, preferably as compile time option? I didn't find
>> such a thing for Intel or Radeon. Don't say, I should rely on userspace here or
>> use fbdev for this.
>
> Just tell the X driver to not use acceleration, and it you won't get
> any acceleration used, then you get complete stability. If a driver
> writer wants to turn off all accel in the kernel driver, it can, its
> not an option we've bothered with for intel or radeon since it really
> makes no sense. To put it simply you don't really seem to understand
> the driver model around KMS. If no userspace app uses acceleration
> then no acceleration features will magically happen. If you want to
> write a simple app against the KMS API like plymouth you can now use
> the dumb ioctls to create and map a buffer that can be made into a
> framebuffer. Also you get hw cursors + modesetting.
Again, you seem to not understand my reasoning. The "if" is the problem, it's
the kernels job to ensure stability. Allowing the userspace to decide whether it
crashes my machine is not acceptable to me.
I do not claim that it is impossible to write a KMS driver in a way that it does
not crash, but it seems more difficult than writing an fbdev driver.
>> The thing is that the core fbdev API does not expose any acceleration to
>> userspace, maybe some drivers do via IOCTLs, but I hope that are only things
>> that can be done in a sane way, otherwise I'd consider it a bug. The story is
>> different for DRM/KMS, as I understand, as this was primarily for acceleration
>> and only recently got modesetting capabilities.
>
> The core drm/kms ioctls don't expose acceleration to userspace either,
> again misinformation seems to drive most of your logic. You can't do
> generic useful acceleration from the kernel. A lot of modern GPU
> hardware doesn't even have bitblt engines.
I did not say that it is used directly for acceleration, but wasn't the point of
DRM to allow acceleration in the first place?
>> It's true that mmap can be PITA, but I don't see any real alternative given that
>> you want directly map video memory, especially on low end systems. And there are
>> ways around it, you can forbid mapping (though probably most userspace wouldn't
>> like it, I guess) or use any other solution like defio.
>> If you'd stop exposing the fbdev userspace interface it'd just harden my opinion
>> that KMS is a piece of trash and that I should avoid hardware that does not have
>> a native framebuffer driver. I think you shouldn't do this, as it's just a
>> disadvantage for your end users, but I personally do not really care.
>
> We've fixed this in KMS, we don't pass direct mappings to userspace
> that we can't tear down and refault. We only provide objects via
> handles. The only place its a problem is where we expose fbdev legacy
> emulation, since we have to fix the pages.
I guess we could do the same in fbdev. It's probably just that nobody is
interested in it as we do not really care about memory management.
Best regards,
Florian Tobias Schandinat
^ permalink raw reply
* Re: Proposal for a low-level Linux display framework
From: Dave Airlie @ 2011-09-17 18:23 UTC (permalink / raw)
To: Florian Tobias Schandinat
Cc: linux-fbdev, linaro-dev, linux-kernel, dri-devel, Archit Taneja,
Rob Clark
In-Reply-To: <4E74E3D6.8080401@gmx.de>
>
> Is it? Well, okay, I don't want to use any acceleration that can crash my
> machine, where can I select it, preferably as compile time option? I didn't find
> such a thing for Intel or Radeon. Don't say, I should rely on userspace here or
> use fbdev for this.
Just tell the X driver to not use acceleration, and it you won't get
any acceleration used, then you get complete stability. If a driver
writer wants to turn off all accel in the kernel driver, it can, its
not an option we've bothered with for intel or radeon since it really
makes no sense. To put it simply you don't really seem to understand
the driver model around KMS. If no userspace app uses acceleration
then no acceleration features will magically happen. If you want to
write a simple app against the KMS API like plymouth you can now use
the dumb ioctls to create and map a buffer that can be made into a
framebuffer. Also you get hw cursors + modesetting.
> The thing is that the core fbdev API does not expose any acceleration to
> userspace, maybe some drivers do via IOCTLs, but I hope that are only things
> that can be done in a sane way, otherwise I'd consider it a bug. The story is
> different for DRM/KMS, as I understand, as this was primarily for acceleration
> and only recently got modesetting capabilities.
The core drm/kms ioctls don't expose acceleration to userspace either,
again misinformation seems to drive most of your logic. You can't do
generic useful acceleration from the kernel. A lot of modern GPU
hardware doesn't even have bitblt engines.
> It's true that mmap can be PITA, but I don't see any real alternative given that
> you want directly map video memory, especially on low end systems. And there are
> ways around it, you can forbid mapping (though probably most userspace wouldn't
> like it, I guess) or use any other solution like defio.
> If you'd stop exposing the fbdev userspace interface it'd just harden my opinion
> that KMS is a piece of trash and that I should avoid hardware that does not have
> a native framebuffer driver. I think you shouldn't do this, as it's just a
> disadvantage for your end users, but I personally do not really care.
We've fixed this in KMS, we don't pass direct mappings to userspace
that we can't tear down and refault. We only provide objects via
handles. The only place its a problem is where we expose fbdev legacy
emulation, since we have to fix the pages.
Dave.
^ permalink raw reply
* Re: Proposal for a low-level Linux display framework
From: Florian Tobias Schandinat @ 2011-09-17 18:15 UTC (permalink / raw)
To: Dave Airlie
Cc: Rob Clark, Felipe Contreras, Alan Cox, linaro-dev, linux-kernel,
dri-devel, Archit Taneja, linux-fbdev
In-Reply-To: <CAPM=9twmPVrBPmUuEuTYHSzjDGHtfsmiVX6cozpAFYEaV-NcCg@mail.gmail.com>
On 09/17/2011 04:47 PM, Dave Airlie wrote:
>>
>> I disagree. This depends on the functionality the hardware has, the desired
>> userspace and the manpower one has to do it. And of course if you just want fb
>> having fb via DRM/KMS has some overhead/bloat. It's perfectly okay to have just
>> an fb driver for devices that can't do more anyway.
>> And fb is no legacy interface but actively developed, just with other goals than
>> DRM/KMS is, it aims for stability and to provide a direct interface, not needing
>> any X or wayland crap.
>
> Stability is a total misnomer, whats worse is you know it. If you just
> want to do software render your whole GUI whether you use KMS or fbdev
> doesn't matter. Instability is only to do with GPU hardware
> acceleration, whether fb or kms expose accel doesn't matter. So less
> attitude please.
Is it? Well, okay, I don't want to use any acceleration that can crash my
machine, where can I select it, preferably as compile time option? I didn't find
such a thing for Intel or Radeon. Don't say, I should rely on userspace here or
use fbdev for this.
The thing is that the core fbdev API does not expose any acceleration to
userspace, maybe some drivers do via IOCTLs, but I hope that are only things
that can be done in a sane way, otherwise I'd consider it a bug. The story is
different for DRM/KMS, as I understand, as this was primarily for acceleration
and only recently got modesetting capabilities.
> fbdev is totally uninteresting for any modern multi-output hardware
> with an acceleration engine, you can't even memory manage the GPU
> memory in any useful way, try resizing the fb console dynamically when
> you've allocated the memory immediately following it in VRAM, you
> can't as userspace has it direct mapped, with no way to remove the
> mappings or repage them. Even now I'm still thinking we should do
> kmscon without exposing the fbdev interface to userspace because the
> whole mmap semantics are totally broken, look at the recent fb
> handover race fixes.
It's true that mmap can be PITA, but I don't see any real alternative given that
you want directly map video memory, especially on low end systems. And there are
ways around it, you can forbid mapping (though probably most userspace wouldn't
like it, I guess) or use any other solution like defio.
If you'd stop exposing the fbdev userspace interface it'd just harden my opinion
that KMS is a piece of trash and that I should avoid hardware that does not have
a native framebuffer driver. I think you shouldn't do this, as it's just a
disadvantage for your end users, but I personally do not really care.
Regards,
Florian Tobias Schandinat
^ permalink raw reply
* Re: Proposal for a low-level Linux display framework
From: Rob Clark @ 2011-09-17 16:50 UTC (permalink / raw)
To: Florian Tobias Schandinat
Cc: linux-fbdev, linaro-dev, linux-kernel, dri-devel, Archit Taneja
In-Reply-To: <4E74C6C3.2000704@gmx.de>
On Sat, Sep 17, 2011 at 11:11 AM, Florian Tobias Schandinat
<FlorianSchandinat@gmx.de> wrote:
> On 09/17/2011 03:16 PM, Rob Clark wrote:
>>>From userspace perspective, fbdev doesn't go away. It is just a
>> legacy interface provided on top of DRM/KMS driver mostly via helper
>> functions. With this approach, you get the richer KMS API (and all
>> the related plumbing for hotplug, EDID parsing, multi-head support,
>> flipping, etc) for userspace stuff that needs that, but can keep the
>> fbdev userspace interface for legacy apps. It is the best of both
>> worlds. There isn't really any good reason to propagate standalone
>> fbdev driver anymore.
>
> I disagree. This depends on the functionality the hardware has, the desired
> userspace and the manpower one has to do it. And of course if you just want fb
> having fb via DRM/KMS has some overhead/bloat. It's perfectly okay to have just
> an fb driver for devices that can't do more anyway.
> And fb is no legacy interface but actively developed, just with other goals than
> DRM/KMS is, it aims for stability and to provide a direct interface, not needing
> any X or wayland crap.
Hmm, for simple enough devices, maybe fb is fine.. but if you are
covering a range of devices which include stuff with more
sophisticated userspace (X/wayland), then just doing DRM/KMS and using
the DRM fbdev helpers, vs doing both DRM/KMS and standalone fbdev..
well that seems like a no-brainer.
I still think, if you are starting a new driver, you should just go
ahead and use DRM/KMS.. a simple DRM/KMS driver that doesn't support
all the features is not so complex, and going this route future-proofs
you better when future generations of hardware gain more capabilities
and sw gain more requirements.
BR,
-R
>
> Best regards,
>
> Florian Tobias Schandinat
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
^ permalink raw reply
* Re: Proposal for a low-level Linux display framework
From: Dave Airlie @ 2011-09-17 16:47 UTC (permalink / raw)
To: Florian Tobias Schandinat
Cc: linux-fbdev, linaro-dev, linux-kernel, dri-devel, Archit Taneja,
Rob Clark
In-Reply-To: <4E74C6C3.2000704@gmx.de>
>
> I disagree. This depends on the functionality the hardware has, the desired
> userspace and the manpower one has to do it. And of course if you just want fb
> having fb via DRM/KMS has some overhead/bloat. It's perfectly okay to have just
> an fb driver for devices that can't do more anyway.
> And fb is no legacy interface but actively developed, just with other goals than
> DRM/KMS is, it aims for stability and to provide a direct interface, not needing
> any X or wayland crap.
Stability is a total misnomer, whats worse is you know it. If you just
want to do software render your whole GUI whether you use KMS or fbdev
doesn't matter. Instability is only to do with GPU hardware
acceleration, whether fb or kms expose accel doesn't matter. So less
attitude please.
fbdev is totally uninteresting for any modern multi-output hardware
with an acceleration engine, you can't even memory manage the GPU
memory in any useful way, try resizing the fb console dynamically when
you've allocated the memory immediately following it in VRAM, you
can't as userspace has it direct mapped, with no way to remove the
mappings or repage them. Even now I'm still thinking we should do
kmscon without exposing the fbdev interface to userspace because the
whole mmap semantics are totally broken, look at the recent fb
handover race fixes.
Dave.
Dave.
^ permalink raw reply
* Re: Proposal for a low-level Linux display framework
From: Florian Tobias Schandinat @ 2011-09-17 16:11 UTC (permalink / raw)
To: Rob Clark; +Cc: linux-fbdev, linaro-dev, linux-kernel, dri-devel, Archit Taneja
In-Reply-To: <CAF6AEGu2-O+2KuCrQPJ6-xejg8TCScrFVZSimgkAV_5Xs-bgkg@mail.gmail.com>
On 09/17/2011 03:16 PM, Rob Clark wrote:
>>From userspace perspective, fbdev doesn't go away. It is just a
> legacy interface provided on top of DRM/KMS driver mostly via helper
> functions. With this approach, you get the richer KMS API (and all
> the related plumbing for hotplug, EDID parsing, multi-head support,
> flipping, etc) for userspace stuff that needs that, but can keep the
> fbdev userspace interface for legacy apps. It is the best of both
> worlds. There isn't really any good reason to propagate standalone
> fbdev driver anymore.
I disagree. This depends on the functionality the hardware has, the desired
userspace and the manpower one has to do it. And of course if you just want fb
having fb via DRM/KMS has some overhead/bloat. It's perfectly okay to have just
an fb driver for devices that can't do more anyway.
And fb is no legacy interface but actively developed, just with other goals than
DRM/KMS is, it aims for stability and to provide a direct interface, not needing
any X or wayland crap.
Best regards,
Florian Tobias Schandinat
^ permalink raw reply
* Re: Proposal for a low-level Linux display framework
From: Rob Clark @ 2011-09-17 15:16 UTC (permalink / raw)
To: Felipe Contreras
Cc: linux-fbdev, linaro-dev, Florian Tobias Schandinat, linux-kernel,
dri-devel, Archit Taneja
In-Reply-To: <CAMP44s1ywhCV+FaudnwjwJUvj5Cf3_oz1M++kjXxRDGQpJ6-0w@mail.gmail.com>
On Sat, Sep 17, 2011 at 9:44 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Thu, Sep 15, 2011 at 9:58 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>>> One of my biggest problems with KMS is that it has (naturally) a lot more
>>> complexity than the fb API which leads to instability. Basically it's very
>>
>> It shouldn't do - and a sample of one (your machine) is not a
>> statistically valid set. Fb is pretty much ununsable in contrast on my
>> main box, but that's not a statistically valid sample either.
>>
>> I'm not that convinced by the complexity either. For a simple video card
>> setup such as those that the fb layer can kind of cope with (ie linear
>> buffer, simple mode changes, no client rendering, no vblank flipping,
>> limited mode management, no serious multi-head) a DRM driver is also
>> pretty tiny and simple.
>
> That's not true, many drivers work around the lack of features in the
> fb API by providing custom interfaces. For example, in omapfb it's
> possible to use the overlays from user-space, configure some YUV
> format, do vsink, and multipages just fine:
>
> https://github.com/felipec/gst-omapfb/blob/master/omapfb.c
>
> It's perfect to render video clips. Of course, it would be even better
> if those custom interfaces were merged into the fb API.
fwiw, as was mentioned earlier in the thread, there is already an
effort underway for a standardized overlay interface for KMS:
http://lists.freedesktop.org/archives/dri-devel/2011-April/010559.html
Anyways, it is also possible to extend DRM drivers w/ custom API.. and
even possible extend the fbdev on top of DRM/KMS with custom
interfaces if you *really* wanted to. I have some patches somewhere
that add support a portion of the omapfb ioctls to the fbdev layer in
omapdrm driver for the benefit of some legacy display test app. If
someone really wanted to, I guess there is no reason that you couldn't
support all of the omapfb custom ioctls.
From userspace perspective, fbdev doesn't go away. It is just a
legacy interface provided on top of DRM/KMS driver mostly via helper
functions. With this approach, you get the richer KMS API (and all
the related plumbing for hotplug, EDID parsing, multi-head support,
flipping, etc) for userspace stuff that needs that, but can keep the
fbdev userspace interface for legacy apps. It is the best of both
worlds. There isn't really any good reason to propagate standalone
fbdev driver anymore.
BR,
-R
> --
> Felipe Contreras
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
^ permalink raw reply
* Re: Proposal for a low-level Linux display framework
From: Felipe Contreras @ 2011-09-17 14:44 UTC (permalink / raw)
To: Alan Cox
Cc: Florian Tobias Schandinat, Alex Deucher, Keith Packard,
linux-fbdev, linaro-dev, linux-kernel, dri-devel, Archit Taneja,
Clark, Rob
In-Reply-To: <20110915195804.4e6d965b@lxorguk.ukuu.org.uk>
On Thu, Sep 15, 2011 at 9:58 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> One of my biggest problems with KMS is that it has (naturally) a lot more
>> complexity than the fb API which leads to instability. Basically it's very
>
> It shouldn't do - and a sample of one (your machine) is not a
> statistically valid set. Fb is pretty much ununsable in contrast on my
> main box, but that's not a statistically valid sample either.
>
> I'm not that convinced by the complexity either. For a simple video card
> setup such as those that the fb layer can kind of cope with (ie linear
> buffer, simple mode changes, no client rendering, no vblank flipping,
> limited mode management, no serious multi-head) a DRM driver is also
> pretty tiny and simple.
That's not true, many drivers work around the lack of features in the
fb API by providing custom interfaces. For example, in omapfb it's
possible to use the overlays from user-space, configure some YUV
format, do vsink, and multipages just fine:
https://github.com/felipec/gst-omapfb/blob/master/omapfb.c
It's perfect to render video clips. Of course, it would be even better
if those custom interfaces were merged into the fb API.
--
Felipe Contreras
^ permalink raw reply
* Re: Proposal for a low-level Linux display framework
From: Alan Cox @ 2011-09-16 16:53 UTC (permalink / raw)
To: Keith Packard
Cc: linux-fbdev, linaro-dev, linux-kernel, dri-devel, Archit Taneja,
Clark, Rob
In-Reply-To: <yunfwjxwbjq.fsf@aiko.keithp.com>
> I'm not sure a common interface to all of these different
> channels makes sense, but surely a DSI library and an aux channel
> library would fit nicely alongside the existing DDC library.
DSI and the various other MIPI bits tend to be horribly panel and device
specific. In one sense yes its a standard with standard commands,
processes, queries etc, on the other a lot of stuff is oriented around
the 'its a fixed configuration unit we don't need to have queries' view.
There also tends to be a lot of vendor magic initialisation logic both
chipset and device dependant, and often 'plumbing dependant' on SoC
systems. This is doubly ugly with the I²C abstractions for DDC because
SoC systems are not above putting the DDC on a standard I²C port being
shared with other functionality.
> Oh, I think you're also trying to get at how we expose some of these
> controls outside of the display driver -- right now, they're mostly
> exposed as properties on the output device. Things like backlight
> brightness, a million analog TV output values, dithering control and
> other more esoteric controls.
This is how the MIPI handling in the GMA500 driver works, although the
existing code needs to be taken out and shot, which should be happening
soon. There is a lot, like panel initialisation which is however not
really going to fit a properties model.
Alan
^ permalink raw reply
* Re: Proposal for a low-level Linux display framework
From: Daniel Vetter @ 2011-09-16 14:17 UTC (permalink / raw)
To: Keith Packard
Cc: Tomi Valkeinen, linux-fbdev, linaro-dev, linux-kernel, dri-devel,
Archit Taneja, Clark, Rob
In-Reply-To: <yunfwjxwbjq.fsf@aiko.keithp.com>
On Thu, Sep 15, 2011 at 07:55:37PM -0500, Keith Packard wrote:
> I suspect helper functions would be a good model to follow, rather than
> trying to create a whole new device infrastructure; some of the
> communication paths aren't easily separable from the underlying output
> devices.
This. Helper functions make the driver writers life so much easier - if
your hw doesn't quite fit the model, you can usually extend functionality
with much less fuzz than if there's a full framework. This is also pretty
much the reason, why I don't like ttm.
-Daniel
--
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48
^ permalink raw reply
* ***Western Union Payment Alert***
From: WESTERN UNION MONEY TRANSFER @ 2011-09-16 13:21 UTC (permalink / raw)
To: linux-fbdev
Good day,
I write to inform you that we have already sent you $5000.00 USD dollars through Western Union as we have been given the mandate to transfer your full compensation payment of $2.5Million Dollars via Western Union by the United Nations Government.So I decided to email you the MTCN and sender's name so you can pick up this $5000.00 USD to enable us send another $5000.00USD by tomorrow as you know we will be sending you only $5000.00 USD per day. Please pick up this information and run to any Western Union in your country to pick up the $5000.00 USD and call me back to send you another payment tomorrow. However we have noted you as a customer of western union money transfer.
Manager: Mr Alfred Dennis.
Email: wumt66655@yahoo.com.hk
Call or email me once you picked up this $5,000 USD today. Here is the western union information below.
SENDERS FIRST NAME :_____EMEKA
SENDER’S LAST NAME:_____ ONWUESI
MTCN:__________________ 6210476549
Amount;=___________________$5,000, USD
Test Question;= ___________Honest?
Test Answer;= _____________Trust
You have to track your Payment information on below Western union website before you locate any western union office.
https://wumt.westernunion.com/asp/orderStatus.asp?country=global
Regards,
Mr Alfred Dennis.
^ permalink raw reply
* Re: [PATCHv2 09/15] OMAP: DSS2: HDMI: implement detect()
From: K, Mythri P @ 2011-09-16 12:53 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Rob Clark, linux-omap, linux-fbdev, archit
In-Reply-To: <1316068371.1880.25.camel@deskari>
Hi,
On Thu, Sep 15, 2011 at 12:02 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On Thu, 2011-09-15 at 11:54 +0530, K, Mythri P wrote:
>> Hi,
>>
>> On Thu, Sep 15, 2011 at 11:27 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> > On Thu, 2011-09-15 at 11:11 +0530, K, Mythri P wrote:
>> >> Hi,
>> >>
>> >> On Wed, Sep 14, 2011 at 7:41 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> >
>> >> > Yes, you are right, detect() does not "know" if the monitor has changed
>> >> > between polls, so both notification and polling are needed. I
>> >> > implemented only polling as there's no HPD event mechanism yet in
>> >> > omapdss, and also because this was simple and gives DRM basic ability to
>> >> > detect a monitor.
>> >> >
>> >> If it is needed for DRM then it is fine, but with detect renamed to
>> >> poll. By next week i should have a patch ready for HPD event
>> >> mechanism.
>> >
>> > What is wrong with "detect"? It detects if there's a display connected.
>> > It can be used in polling manner, trying it every n seconds, but it
>> > should also be used even if you use HPD event. I think the normal
>> > sequence would be something like:
>> >
>> > 1) register HPD event
>> > 2) use detect() to see if a monitor is already connected
>> >
>> I guess polling ever few seconds to detect would be waste of CPU
>> cycles when there is already a mechanism in the H/w to detect the
>> connection.
>
> Obviously. Polling is only used if hot-plug-detect is not available. But
> detect function can be used even when HPD is available.
>
>> Current sequence :
>> Enable display ( Irrespective of whether the cable is connected on not)
>>
>> Sequence with HPD:
>> 1.Register for HPD connect.
>> 2.Enable display
>> 3.Notify DRM/Audio/Kernel component that wants to listen to this event.
>
> Why would you enable the display even if there's no monitor connected?
>
> And when the DRM starts, how does DRM know if the display was already
> connected? Would you send a HPD event when DRM registers to the event
> even if there's no actual plug-in event done (i.e. user actually
> connecting the cable)?
>
HPD event would be triggered only when the cable is connected , and
the EDID is ready to be read by the monitor. So the question enabling
display doesnt exist. When HDMI is enabled in the HPD mode it will be
in minimal power mode.
Yes then the driver will notify DRM/any module that cable(monitor) is
now connected.
> And just to clarify, my sequence example was from DRM's point of view.
> The HDMI driver shouldn't do anything before DRM/omapfb asks it to do
> something.
>
> Tomi
>
>
>
Thanks and regards,
Mythri.
^ permalink raw reply
* Re: Proposal for a low-level Linux display framework
From: Tomi Valkeinen @ 2011-09-16 6:38 UTC (permalink / raw)
To: Keith Packard
Cc: linux-fbdev, linux-kernel, dri-devel, linaro-dev, Clark, Rob,
Archit Taneja
In-Reply-To: <yunfwjxwbjq.fsf@aiko.keithp.com>
On Thu, 2011-09-15 at 19:55 -0500, Keith Packard wrote:
> On Thu, 15 Sep 2011 20:21:15 +0300, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>
> > 2) panel drivers, handles panel specific things. Each panel may support
> > custom commands and features, for which we need a dedicated driver. And
> > this driver is not platform specific, but should work with any platform
> > which has the output used with the panel.
>
> Right, we've got DDC ports (which are just i2c) and DisplayPort aux
> channel stuff.
>
> The DDC stuff is abstracted out and shared across the drivers, but the
> DisplayPort aux channel code is not -- it's duplicated in every output
> driver.
I feel that you are still talking about the output driver, not the
panel. DDC and DP aux are part of the connector-entity in DRM, right?
But there's no separate display-entity behind the connector, which would
handle the peculiarities for a particular panel/display, say DSI panel
model L33T from AcmeCorp.
So, as I see it, DDC and DP aux are on the output driver, and the panel
driver uses those to do whatever is needed for a particular panel.
> > DSI bus is a half-duplex serial bus, and while it's designed for
> > displays you could use it easily for any communication between the SoC
> > and the peripheral.
>
> Yeah, HDMI uses DDC for all kinds of crazy stuff in the CE world.
But that is still more or less standard HDMI stuff, isn't it? So you
implement it once for HDMI, and then it works with all HDMI monitors?
Or is there some way to implement custom behavior for one particular
HDMI monitor? Is this custom behavior in a kernel driver or handled in
userspace?
> > The point is that we cannot have standard "MIPI DSI command mode panel
> > driver" which would work for all DSI cmd mode panels, but we need (in
> > the worst case) separate driver for each panel.
>
> It sounds like we do want to share code for those bits, much like we
> have DDC split out now. And, we should do something about the
> DisplayPort aux channel stuff to avoid duplicating it everywhere.
Yep. What I had in mind for DSI with my low-level fmwk would be a
mipi_dsi component that offers services to use the DSI bus. Each
platform which supports DSI would implement the DSI support for their
HW. Then the DSI panel driver could do things like:
dsi->write(dev, virtual_channel_id, buf, len);
dsi->set_max_return_packet_size(dev, 10);
dsi->read(dev, virtual_channel_id, read_cmd, recv_buf, len);
An example DSI command mode panel driver can be found from
drivers/video/omap2/displays/panel-taal.c, which uses omapdss' dsi
functions directly but could quite easily use a common DSI interface and
thus be platform independent.
> I'm not sure a common interface to all of these different
> channels makes sense, but surely a DSI library and an aux channel
> library would fit nicely alongside the existing DDC library.
What do you mean with "channel"? Any video or command bus going to the
display? Yes, I think they are quite different and I don't see a point
in trying to make a common interface for them.
DSI is in many ways a real bus. You can connect multiple peripherals to
one DSI bus (but it needs a DSI hub), and communicate with them by using
their virtual channel ID. And quite often there are DSI chips that
transform the DSI packets to some other form. Some real example
configurations:
Plain DSI panel:
[SoC] ---DSI--- [DSI panel]
DSI-2-DisplayPort converter chip:
[SoC] ---DSI--- [DSI chip] ---DP--- [DP monitor]
DSI buffer chip supporting to DSI panels:
[SoC] ---DSI--- [DSI chip] +--DSI--- [DSI panel 1]
|--DSI--- [DSI panel 2]
It would be nice to be able to model this somehow neatly with device
drivers. For example, the DSI panel from the first example could be used
in the two-panel configuration, and if (and when) the panel requires
custom configuration, the same panel driver could be used in both cases.
In the first case the panel driver would use DSI support from the Soc,
in the third case the panel driver would use the DSI support from the
DSI chip (which would, in turn, use DSI support from the SoC).
Tomi
^ permalink raw reply
* Re: Proposal for a low-level Linux display framework
From: Keith Packard @ 2011-09-16 4:53 UTC (permalink / raw)
To: Florian Tobias Schandinat, Alex Deucher
Cc: linux-fbdev, linaro-dev, linux-kernel, dri-devel, Archit Taneja,
Clark, Rob
In-Reply-To: <4E724659.5080709@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 1676 bytes --]
On Thu, 15 Sep 2011 18:39:21 +0000, Florian Tobias Schandinat <FlorianSchandinat@gmx.de> wrote:
> Well, I'm not against sharing the code and not against taking DRM's current
> implementation as a base but the steps required to make it generally acceptable
> would be to split it of, probably as a standalone module and strip all DRM
> specific things off. Than all things that require EDID can use it, DRM can add
> DRM-specific things on top and fb can add fb-specific things.
The rendering portions of the DRM drivers are all device-specific. The
core DRM ioctls are largely about providing some sharing control over
the device, mapping memory around and mode setting.
> One of my biggest problems with KMS is that it has (naturally) a lot more
> complexity than the fb API which leads to instability.
The mode setting portions are of necessity the same. The KMS API exposes
more functionality for mode setting, but doesn't actually require any
additional hardware-specific knowledge. You still have to be able to
bring the hardware up from power on and light up every connected
monitor.
However, if you want acceleration, you're going to run into bugs that
crash the machine. It's a sad reality that graphics hardware just isn't
able to recover cleanly in all cases from programmer errors, and that
includes errors that come from user mode.
Hardware is improving in this area, and reset is getting more reliable
than it used to be. But, until we can context switch the graphics
hardware at arbitrary points during execution, we're kinda stuck with
using the really big reset hammer when programs go awry.
--
keith.packard@intel.com
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox