Re: [PATCH 0/2] video: s3c-fb: Add window positioning support

2011-09-18 Thread Florian Tobias Schandinat
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

2011-09-18 Thread Laurent Pinchart
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

2011-09-07 Thread Laurent Pinchart
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

2011-09-06 Thread Ajay kumar
Hi Florian,

On Thu, Sep 1, 2011 at 10:15 PM, Florian Tobias Schandinat
florianschandi...@gmx.de 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

2011-09-02 Thread Tomi Valkeinen
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

2011-09-01 Thread Florian Tobias Schandinat
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

2011-08-25 Thread Ajay Kumar
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