Re: [PATCH 0/2] video: s3c-fb: Add window positioning support
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
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] video: s3c-fb: Add window positioning support
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 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] video: s3c-fb: Add window positioning support
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 ? > So let me at first summarize how I understand you implemented those things > after having a brief look at some of the drivers: > Windows are rectangular screen areas whose pixel data come from other > locations. The other locations are accessible via other framebuffer > devices (e.g. fb1). So in this area the data of fb1 is shown and not the > data of fb0 that would be normally shown. > > So in addition to your proposed positioning I think we should also have the > following to give userspace a useful set of functionality: > > - a way to discover how the screen is composited (how many windows are > there, how they are stacked and how to access those) > > - a way to enable/disable windows (make them (in)visible) > > - reporting and selecting how the window content can be mixed with the root > screen (overwrite, source or destination color keying) > > - things like window size and color format could be handled by the usual fb > API used on the window. However there might be restrictions which cause > them to be not 100% API compatible (for example when changing the color > format if the windows are required to have the same format as the root > screen) > > - do we need to worry about hardware (up/down) scaling of the window > content? > > > So is that what you need for a standardized window implementation? > Any additional things that were useful/needed in this context? > Would you consider adding support for this API in your drivers? (as > standardizing wouldn't be useful if nobody would implement it) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] video: s3c-fb: Add window positioning support
Hi Florian, On Thu, Sep 1, 2011 at 10:15 PM, 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). Thanks for considering the scenerio. Yes, you are right and we need to start somewhere. > So let me at first summarize how I understand you implemented those things > after > having a brief look at some of the drivers: > Windows are rectangular screen areas whose pixel data come from other > locations. > The other locations are accessible via other framebuffer devices (e.g. fb1). > So > in this area the data of fb1 is shown and not the data of fb0 that would be > normally shown. Yes, thats right! The area not covered by the other framebuffer device/window (e.g. fb1) will be transparent and the framebuffer device/window below (e.g. fb0) will be visible. > So in addition to your proposed positioning I think we should also have the > following to give userspace a useful set of functionality: > > - a way to discover how the screen is composited (how many windows are there, > how they are stacked and how to access those) This will need more discussions, as the amount of information to be exposed to the user-space might vary from controller-to-controller. > - a way to enable/disable windows (make them (in)visible) This is already present. Switching on/off any particular framebuffer device/window can be done by calling ioctl with FBIOBLANK, from user space. > - reporting and selecting how the window content can be mixed with the root > screen (overwrite, source or destination color keying) Yes, thats a good point. This can be achieved by implementing ioctl call > - things like window size and color format could be handled by the usual fb > API > used on the window. However there might be restrictions which cause them to be > not 100% API compatible (for example when changing the color format if the > windows are required to have the same format as the root screen) This seems to be more to do with the property of the FB controller. Moreover, the driver can always enforce checks on such hardware restrictions. > - do we need to worry about hardware (up/down) scaling of the window content? The user application should take care of these functions, as this is directly related to the window size. (Usually these operations are handled by some separate hardware modules (post-processors) ) > > So is that what you need for a standardized window implementation? > Any additional things that were useful/needed in this context? > Would you consider adding support for this API in your drivers? (as > standardizing wouldn't be useful if nobody would implement it) Yes, having these missing features will definitely give the user much more control over the various available framebuffer devices/windows. We would like to start with the fb window re-positioning feature and add more features in coming days. > > Best regards, > > Florian Tobias Schandinat > Thanks for your review and suggestions. It was very helpful. Best Regards, Ajay Kumar -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] video: s3c-fb: Add window positioning support
Hi, On Thu, 2011-09-01 at 16:45 +, 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). > > So let me at first summarize how I understand you implemented those things > after > having a brief look at some of the drivers: > Windows are rectangular screen areas whose pixel data come from other > locations. > The other locations are accessible via other framebuffer devices (e.g. fb1). > So > in this area the data of fb1 is shown and not the data of fb0 that would be > normally shown. Here's what we have on OMAP: We have a bunch of hardware overlays, each of which can go to one output. When using fbdev, the pixel data for overlays comes from the framebuffers. One fb can be used as a pixel source for multiple overlays. So, for example, the "connections" can be like these: Initial configuration .-. .--. .--. | fb0 |>| ovl0 |-.>| LCD | '-' '--' | '--' .-. .--. | | fb1 |>| ovl1 |-| '-' '--' | .-. .--. | .--. | fb2 |>| ovl2 |-' | TV | '-' '--' '--' Video on fb1, shown on LCD and TV .-. .--. .--. | fb0 |>| ovl0 |-.>| LCD | '-' '--' | '--' .-. .--. | | fb1 |.--->| ovl1 |-' '-'|'--' .-.|.--. .--. | fb2 |'--->| ovl2 |-->| TV | '-' '--' '--' And how the actual image is composited on the display, we have first the fb side (no news there): .-fb-vxres-. | | | | | (xoffset,yoffset) | | .---fb-xres. | f | | | b f | | | b | | v | | | y y | | r r | | e e | | s s | | | | | | | '--' | | | | | '--' The area marked by x/yoffset and x/yres is used as the pixel source for the overlay. On the display we have something like this: .disp-xres. | | | (xpos,ypos) | | .-ovl-xres-. | d | | | i o | | s v | | p l | | | | | | y y | | r r | | e e | | s s | | | | | | | '--' | | | '-' The x/ypos of the overlay does not have any relation to the x/yoffset of the framebuffer. The overlay's x/yres is the same as the fb's x/yres in case the overlay doesn't support scaling (OMAP's case this is true for overlay0). Otherwise the overlay's x/yres is only limited by the HW's scaling capabilities. The overlays have a priority order, and where there's no overlay, a background color is used. So like this: .-. |background color | | .---. | | | ovl0 | | | | | | | | .--. | | | | | ovl1 | | | | | | | | | | | |.---.| | | || ovl2|| | | '
Re: [PATCH 0/2] video: s3c-fb: Add window positioning support
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).
So let me at first summarize how I understand you implemented those things after
having a brief look at some of the drivers:
Windows are rectangular screen areas whose pixel data come from other locations.
The other locations are accessible via other framebuffer devices (e.g. fb1). So
in this area the data of fb1 is shown and not the data of fb0 that would be
normally shown.
So in addition to your proposed positioning I think we should also have the
following to give userspace a useful set of functionality:
- a way to discover how the screen is composited (how many windows are there,
how they are stacked and how to access those)
- a way to enable/disable windows (make them (in)visible)
- reporting and selecting how the window content can be mixed with the root
screen (overwrite, source or destination color keying)
- things like window size and color format could be handled by the usual fb API
used on the window. However there might be restrictions which cause them to be
not 100% API compatible (for example when changing the color format if the
windows are required to have the same format as the root screen)
- do we need to worry about hardware (up/down) scaling of the window content?
So is that what you need for a standardized window implementation?
Any additional things that were useful/needed in this context?
Would you consider adding support for this API in your drivers? (as
standardizing wouldn't be useful if nobody would implement it)
Best regards,
Florian Tobias Schandinat
>
> For instance, we can have a common struture and ioctl number in
> include/linux/fb.h as below:
>
> #define FBIOPOS_OVERLAY_WIN_IOW('F', 0x21, struct
> fb_overlay_win_pos)
>
> struct fb_overlay_win_pos {
> __u32 win_pos_x; /* x-offset of window from LCD(0,0) */
> __u32 win_pos_y; /* y-offset of window from LCD(0,0) */
> };
>
> where LCD(0,0) means the first pixel of the LCD screen.
> Individual drivers can have implementation for this ioctl.
>
> To Kukjin Kim,
> [PATCH 1/2] ARM: SAMSUNG: Add Window Positioning Support for s3c-fb driver
>
> To Paul Mundt, Florian Tobias Schandinat
> [PATCH 2/2] video: s3c-fb: Modify s3c-fb driver to support window
> positioning
>
> arch/arm/plat-samsung/include/plat/fb.h | 14 +++
> drivers/video/s3c-fb.c | 37 ++
> 2 files changed, 46 insertions(+), 5 deletions(-)
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] video: s3c-fb: Add window positioning support
These patches are created against "for-next" branch of Kukjin Kim's tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
This patch adds support for positioning of the FB windows on the LCD screen.
This patchset creates an ioctl and defines a data structure which are
specific to samsung SOCs, to hold the window position.
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?
For instance, we can have a common struture and ioctl number in
include/linux/fb.h as below:
#define FBIOPOS_OVERLAY_WIN_IOW('F', 0x21, struct
fb_overlay_win_pos)
struct fb_overlay_win_pos {
__u32 win_pos_x; /* x-offset of window from LCD(0,0) */
__u32 win_pos_y; /* y-offset of window from LCD(0,0) */
};
where LCD(0,0) means the first pixel of the LCD screen.
Individual drivers can have implementation for this ioctl.
To Kukjin Kim,
[PATCH 1/2] ARM: SAMSUNG: Add Window Positioning Support for s3c-fb driver
To Paul Mundt, Florian Tobias Schandinat
[PATCH 2/2] video: s3c-fb: Modify s3c-fb driver to support window positioning
arch/arm/plat-samsung/include/plat/fb.h | 14 +++
drivers/video/s3c-fb.c | 37 ++
2 files changed, 46 insertions(+), 5 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
